On Fri, 12 Nov 2010 16:14:54 -0800 (PST)
Edward K. Ream edream...@gmail.com wrote:
Subject: Terry, can we eliminate the textnode plugin?
It looks like this is the same as @edit. Do you agree?
I agree - I wasn't the original author, just updated it at some point, but I
think it just mirrors
On Mon, Nov 15, 2010 at 1:06 PM, Terry Brown terry_n_br...@yahoo.com wrote:
On Fri, 12 Nov 2010 16:14:54 -0800 (PST)
Edward K. Ream edream...@gmail.com wrote:
Subject: Terry, can we eliminate the textnode plugin?
It looks like this is the same as @edit. Do you agree?
I agree - I wasn't
It looks like the newly-improved handling of @url makes the bookmarks
plugin unnecessary.
I suppose it should remain for those who use it, but would anyone
object if I hide it by not documenting it?
Edward
--
You received this message because you are subscribed to the Google Groups
leo-editor
It looks like this is the same as @edit. Do you agree?
Edward
--
You received this message because you are subscribed to the Google Groups
leo-editor group.
To post to this group, send email to leo-edi...@googlegroups.com.
To unsubscribe from this group, send email to
On Mon, Nov 1, 2010 at 3:08 PM, Terry Brown terry_n_br...@yahoo.com wrote:
just pushed bzr_qcommands.py plugin
Thanks for this work.
...oops, maybe Edward had requested no pushing, oh well, unpushing would just
be more disruptive.
There is no problem with committing to new plugins.
Edward
Plugin loading calls plugin_module.init(), correct?
If that module does
import leo.core.leoGlobals as g
is the g available during init() not the same as the g available in callbacks?
Something in module loading has changed and broken geotag.py which adds an
attrib to g, no big deal, just
On Wed, Nov 3, 2010 at 11:59 AM, Terry Brown terry_n_br...@yahoo.com wrote:
Plugin loading calls plugin_module.init(), correct?
If it exists.
If that module does
import leo.core.leoGlobals as g
is the g available during init() not the same as the g available in callbacks?
I would presume
just pushed bzr_qcommands.py plugin
Add a node context menu with all the bzr q* commands (bzr qt interface)
as submenu. **Requires contextmenu.py.** Bzr is invoked based on the path
of the current node.
...oops, maybe Edward had requested no pushing, oh well, unpushing would just
be more
On Tue, Oct 19, 2010 at 12:44 AM, VR viktor.ransm...@gmail.com wrote:
My immediate need is for '@language rest' since it allows me to write
all my notes into an outline for later usage and processing, while being
able to immediately switch into the web browser whenever I need to ...
Thanks for
On Sun, Oct 17, 2010 at 8:34 AM, VR viktor.ransm...@gmail.com wrote:
* detect_urls.py
* maximizeNewWindows.py
in 'myLeoSettings'.
The 'detect_urls' plugin does not work. It does not report any issues
via the Leo-log or the console. The plugin works fine when using Leo
with Tk as the GUI
On Mon, Oct 18, 2010 at 2:52 PM, Edward K. Ream edream...@gmail.com wrote:
The problem is that detect_urls (colorizeURL's) calls
c.frame.body.tag_add('URL',i,j)
to do the coloring. This is a direct hook into the tk colorer, but
has no effect on the qt.colorer.
Let me see if I can come
for the detect_urls plugin to make such patches
automatically, but doing so might be tricky. It's an initialization
problem and such problems are particularly severe for the qt
colorizer.
Before going further, it would be good to know the languages for which
you need the detect_urls capability
method to specify regex.
...
It would be possible for the detect_urls plugin to make such patches
automatically, but doing so might be tricky. It's an initialization
problem and such problems are particularly severe for the qt
colorizer.
Before going further, it would be good to know
\myLeoSettings.leo
reading settings in D:\Users\Ravi\WL2010.leo
@enabled-plugins found in myLeoSettings.leo
reading: D:\Users\Ravi\WL2010.leo
/Log
Beside the used default plugins from 'LeoSettings' I have only added
* detect_urls.py
* maximizeNewWindows.py
in 'myLeoSettings'.
The 'detect_urls' plugin
Hi Edward,
as an additional info. - The plugin works fine on the same
computer, when I explicitely start Leo with '--gui=tk'
Here is the log:
Log
Leo Log Window
Leo 4.8 devel, build 3005, February 26, 2010
Python 2.6.5, Tk 8.5, Pmw 1.3
Windows 6, 1, 7600, 2,
leoID=ravi20101017 (in D:\Users
placeholder @slide nodes without causing make-slide-show
to waste time.
- Changed a g.note message to use blue rather than hard-to-read
orange.
- LeoDocs.leo now enables the screenshot.py plugin in the @enabled-
plugins node.
Clearly, the tweaks are getting smaller and easier. The version is
now
On Oct 9, 11:56 am, Edward K. Ream edream...@gmail.com wrote:
Rev 3441 contains a few tweaks:
A useful local tweak. I created a key binding for double-click-icon-
box. This is quite important now that I want to open so many @url
files. I recommend that anyone using this plugin define
On Oct 9, 11:56 am, Edward K. Ream edream...@gmail.com wrote:
Clearly, the tweaks are getting smaller and easier. The version is
now 1.0.1. I'm now doing real work on slides.
Rev 3443 contains some more tweaks. Things are *almost* perfect.
There is a problem with @slideshow nodes. Only
On Oct 9, 1:05 pm, Edward K. Ream edream...@gmail.com wrote:
Things are *almost* perfect.
Rev 3446 contains a fairly major tweak: support for @title and
@title_pattern nodes. This is needed to enforce uniform titles
easily. Here is the relevant part of the updated docstring:
Q
@title =
How can I load an abbrev file on the start of leo? For testing I tried
to create a script button:
c.executeMinibufferCommand(read-abbrev-file D:\Dmitry\abbrev)
but it didn't work.
--
You received this message because you are subscribed to the Google Groups
leo-editor group.
To post to this
(or a plugin):
c.abbrevCommands.readAbbreviationsFromFile(fileName)
But this is the hard way. Instead, enable and define your
abbreviations in myLeoSettings.leo (as children of the @settings node)
as follows:
@bool enable-abbreviations = True
@data global-abbreviations
The body text of this node
On Oct 7, 2:44 pm, VR viktor.ransm...@gmail.com wrote:
Is the plug-in functionality available in both GUI's, i.e. Qt Tk ?
At present, no. The plugin uses QPixmap.grabWindow to generate the
screenshot.
If Tk users were willing to get the screenshots by hand, it would be
possible to dispense
. Continuing this thought, instead of creating an @image node,
the plugin will create an @url original screenshot node and an @url
final screenshot node. This is very easy to do.
2. I had thought that the presence or absence of files would be a good
indication of whether to take a new screenshot
is controlling the build process from these @url nodes:
- Nothing happens at all if there is an @url built slide node.
- No screenshot is taken if there is an @url screenshot node.
- No working file is created if there is an @url working file node.
Finally, the plugin now does a make html
On Fri, Oct 8, 2010 at 3:35 PM, Edward K. Ream edream...@gmail.com wrote:
All this gives a powerful yet easy-to-understand workflow. The
version of the plugin is now 1.0 :-)
Next up: explaining this in the docstring...
Done at rev 3436.
EKR
--
You received this message because you
On Thu, Oct 7, 2010 at 12:54 PM, Terry Brown terry_n_br...@yahoo.com wrote:
I think you do need the original, the SVG links to the .png, it doesn't embed
it. If you use the same name for the original and the output I think you
lose the original (it's opened for writing) before the output is
As of rev 3427 the to-do list is empty and the docstring is accurate.
I'll be working on real slideshows today.
Please test the plugin and report any problems immediately.
Early this morning, while revising the docstring, I made the following
changes:
1. Renamed @screenshot-tree to @screenshot
On Oct 7, 8:18 am, Edward K. Ream edream...@gmail.com wrote:
As of rev 3427 the to-do list is empty and the docstring is accurate.
I'll be working on real slideshows today.
It will be best if slides and screenshots are simply called slide-
n.html and screenshot-n.svg/.png. Indeed, the
On Thu, Oct 7, 2010 at 8:18 AM, Edward K. Ream edream...@gmail.com wrote:
As of rev 3427 the to-do list is empty and the docstring is accurate.
I'll be working on real slideshows today.
Please test the plugin and report any problems immediately.
Sorry, I haven't been keeping up; where
On Oct 7, 10:08 am, Edward K. Ream edream...@gmail.com wrote:
Done at rev 3428. Except for bug fixes, I expect this to be the last
significant change.
The final integration test has passed. See:
http://webpages.charter.net/edreamleo/slides.html
Edward
--
You received this message
no attribute 'getPluginModule'
Thanks for this bug report. I'll fix it today.
The workaround is to enable the scrolledmessage.py plugin. It works
for me. And disabling scrolledmessage.py give the error you describe.
Edward
--
You received this message because you are subscribed to the Google Groups
leo
On Thu, Oct 7, 2010 at 10:10 AM, Kent Tenney kten...@gmail.com wrote:
Sorry, I haven't been keeping up; where are instructions for using it?
Besides the docstring test.leo contains a Slideshows node that I used
to create my-first-slide-show.
EKR
--
You received this message because you are
On Thu, Oct 7, 2010 at 12:24 PM, Terry Brown
Is there not a need for three image names, the base screen shot png image (1)
used by the svg (2) to create the final annotated screen shot png image (3)?
Not particularly. You don't need the original if you have the svg
file. It's easy to
On Oct 7, 10:43 am, Edward K. Ream edream...@gmail.com wrote:
runScrolledMessageDialog
sm = leoPlugins.getPluginModule('scrolledmessage')
AttributeError: 'module' object has no attribute 'getPluginModule'
Thanks for this bug report. I'll fix it today.
Done in the trunk at rev
On Thu, 7 Oct 2010 12:37:31 -0500
Edward K. Ream edream...@gmail.com wrote:
Not particularly. You don't need the original if you have the svg
file. It's easy to recreate the svg file. Just delete the svg and
png files.
I think you do need the original, the SVG links to the .png, it doesn't
Hi Edward,
You wrote:
As of rev 3427 the to-do list is empty and the docstring is accurate.
I'll be working on real slideshows today.
Please test the plugin and report any problems immediately.
Is the plug-in functionality available in both GUI's, i.e. Qt Tk ?
With kind regards,
Viktor
On Oct 5, 3:04 pm, Edward K. Ream edream...@gmail.com wrote:
Careful readers will already have discovered the main drawback, namely
that each slideshow folder must contain copies of the build files:
conf.py, leo_toc.html.txt, make.bat and Makefile and the Leo icon,
Leo4-80-border.jpg.
It's
On Oct 6, 7:38 am, Edward K. Ream edream...@gmail.com wrote:
It's better (less confusing), if makes can be done only from the
sphinx folder, leo\doc\html.
Well, that idea is a bust. To get the links in the slideshow correct,
the slideshow *must* be made from the slideshow folder.
BTW, a
I'll leave things where they
are.
Several tweaks *are* going to be useful:
1. Better defaults will reduce unnecessary options.
- Commands will not overwrite screenshots if they already exist. Bye
bye the protect option.
- Commands will not automatically edit.svg files. The plugin will
create
On Wed, 6 Oct 2010 08:29:38 -0700 (PDT)
Edward K. Ream edream...@gmail.com wrote:
- Commands will not automatically edit.svg files. The plugin will
create a default .png file, and the user will be free to edit the .svg
file and save as a .png file.
Having edited bazillions of product images
On Wed, Oct 6, 2010 at 10:49 AM, Terry Brown terry_n_br...@yahoo.com wrote:
Having edited bazillions of product images, I think maximum productivity
might come from having a script generate .pngs for .svgs which are newer than
their .png, to save the user having to futz with the save as
.
Good idea.
Done at rev 3424. This is a *beautiful* tweak.
It's now time to document what we have. I think people are going to
like this plugin!
Edward
--
Edward K. Ream email: edream...@gmail.com
Leo: http
On Oct 4, 5:42 pm, Edward K. Ream edream...@gmail.com wrote:
I expect to be creating real slide shows for Leo's web site later
tonight.
This morning I created a real slideshow. This brought to light some
interesting sphinx build issues. How do we get sphinx to create the
slideshows the way
On Oct 5, 8:57 am, Edward K. Ream edream...@gmail.com wrote:
As I write this I realize that it would be possible to run this fixup
script from the makefile itself.
Yes. Define fixdoc.py in leo\doc\html and in make.bat and makefile
add::
python -m fixdoc
after:
%SPHINXBUILD% -b html
On Tue, Oct 5, 2010 at 9:26 AM, Edward K. Ream edream...@gmail.com wrote:
My *guess* is that fixdoc.py will be the simplest thing that could
possibly work, but only some experimentation will tell for sure.
Testing fixdoc is very easy, so I think I'll go with this.
Edward
--
You received
On Oct 5, 10:11 am, Edward K. Ream edream...@gmail.com wrote:
On Tue, Oct 5, 2010 at 9:26 AM, Edward K. Ream edream...@gmail.com wrote:
My *guess* is that fixdoc.py will be the simplest thing that could
possibly work, but only some experimentation will tell for sure.
Testing fixdoc is
with slides.html
completely--there will be separate sphinx makes for slides. I'll play
with this next. It will involve minor tweaks to the screenshot
plugin.
Edward
--
You received this message because you are subscribed to the Google Groups
leo-editor group.
To post to this group, send email
: but
we might as well throw them in so we can do separate makes.
The screenshot plugin (it really should be called the slideshow
plugin) should copy these files automatically. As impatient as I am,
I think it would be best for the screenshot plugin to do this.
It seems like we are finally nearing
On Sep 17, 11:18 am, Edward K. Ream edream...@gmail.com wrote:
It's pretty clear what is required:
1. Treat @slide nodes as @rst nodes as far as the rst code is
concerned.
2. Get really clear about what the default paths will be, and where
files will go.
This should be finished today.
the plugin assumes we are using sphinx.
2. Get clear about where files will go.
Done. This took most of today. The essential Aha was creating the
slide-show-info command that dumps all the options that get computed
by init(). Before this I had been totally lost. Even so, getting the
file names
On Oct 4, 5:42 pm, Edward K. Ream edream...@gmail.com wrote:
To do:commands must make the **slideshow directory** if it doesn't
exist. (I created it by hand for the initial tests).
Done at rev 3414. Actually, the new code makes directories for all
arguments.
EKR
--
You received this
On Sep 15, 3:01 pm, Edward K. Ream edream...@gmail.com wrote:
As of rev 3397, the screenshots plugin is ready for testing and
probably ready for real use.
Not quite :-) The problem with developmental unit tests (Alt-8 in
test.leo) is that they are *too* good: they create a testing framework
As of rev 3397, the screenshots plugin is ready for testing and
probably ready for real use.
Here are some highlights of recent changes:
1. Every side must start with @slide. This convention is clearer, and
allows users to organize slides as usual.
2. Any @slide node may contain @edit, @pause
On Sun, Sep 12, 2010 at 5:04 PM, Terry Brown terry_n_br...@yahoo.com wrote:
2. Create the **original screenshot file**. This is a PNG file. In
the present scheme, this becomes the **output file** (also a PNG
file).
Note that the SVG workfile links to, rather than embeds, the screenshot
On Mon, Sep 13, 2010 at 9:12 AM, Edward K. Ream edream...@gmail.com wrote:
The remaining issues involve the simplest way to split up the total
work flow so that all it's easy *and safe* to do any particular step
for one or a group of slides. By safe I mean that it's easy to
protect previous
On Sep 13, 11:21 am, Edward K. Ream edream...@gmail.com wrote:
Screenshot directives are simple, easy-to-use and Leonine
Other advantages are becoming apparent. Screenshot directives reduce
the need for slideshow-related settings and corresponding argument to
ScreenShotController.run(). This
On Sep 13, 2:30 pm, Edward K. Ream edream...@gmail.com wrote:
On Sep 13, 11:21 am, Edward K. Ream edream...@gmail.com wrote:
Screenshot directives are simple, easy-to-use and Leonine
Other advantages are becoming apparent
I am going to extend this pattern in two ways: @slide and @select.
On Sun, 12 Sep 2010 11:36:10 -0700 (PDT)
Edward K. Ream edream...@gmail.com wrote:
2. Create the **original screenshot file**. This is a PNG file. In
the present scheme, this becomes the **output file** (also a PNG
file).
Note that the SVG workfile links to, rather than embeds, the
This is what I see in the log pane:
hook failed: close-frame, bound method todoController.close of
leo.plugins.todo.todoController instance at 0x94b6b8c,
leo.plugins.todo
Traceback (most recent call last):
File /home/shadow/leo/leo-current/leo/core/leoPlugins.py, line
325, in callTagHandler
On Sat, Sep 11, 2010 at 3:55 AM, zpcspm zpc...@gmail.com wrote:
File /home/shadow/leo/leo-current/leo/plugins/todo.py, line 391,
in close
g.unregisterHandler(i[0], i[1])
My bad. I forgot to wrap pc.unregisterHandler.
The fix is on the trunk at rev 3374.
Edward
--
You received this
On Sep 10, 8:20 am, Edward K. Ream edream...@gmail.com wrote:
Rev 3367 contains the first working version of the screenshot plugin.
Considerable work remains, especially re settings and files, two inter-
related topics. It looks like all options will have to be Leo
settings. Per-leo-file
On Sep 11, 1:28 pm, Edward K. Ream edream...@gmail.com wrote:
Rev 3377 contains...
*many* path-related improvements.
EKR
--
You received this message because you are subscribed to the Google Groups
leo-editor group.
To post to this group, send email to leo-edi...@googlegroups.com.
To
handlers look something like
this:
def onXEvent (tag,keys):
c = keys.get('c'):
if c:
controller = globalDict.get(c)
controller.doX()
Why not make this a systematic pattern, i.e.implement
c.plugindata('mypluginname') that gets you a dict with persistent data
for that plugin
On Fri, Sep 10, 2010 at 2:55 PM, Edward K. Ream edream...@gmail.com wrote:
Yes. This might be a good idea. It would be a
g.app.pluginsController method, but the idea is the same.
I think it should be directly in c, where people can easily get it.
It doesn't matter where the data is, as long
On Fri, Sep 10, 2010 at 6:57 AM, Ville M. Vainio vivai...@gmail.com wrote:
I think it should be directly in c, where people can easily get it.
Well, it relates to plugins, so
g.app.pluginsController.getPluginData(c,pluginName) seems appropriate.
It's a small matter.
EKR
--
You received this
On Fri, Sep 10, 2010 at 3:10 PM, Edward K. Ream edream...@gmail.com wrote:
On Fri, Sep 10, 2010 at 7:04 AM, Ville M. Vainio vivai...@gmail.com wrote:
I don't see why a developer should know about pluginsController
it's a Leo implementation detail.
No. It has exactly the same status that
Rev 3367 contains the first working version of the screenshot plugin.
Considerable work remains, especially re settings and files, two inter-
related topics. It looks like all options will have to be Leo
settings. Per-leo-file settings should give enough flexibility.
The plugin's docstring
On Fri, 10 Sep 2010 06:20:40 -0700 (PDT)
Edward K. Ream edream...@gmail.com wrote:
Performance of post production (inkscape) code is not good. I'll see
where the bottlenecks are.
I think Inkscape takes an annoyingly long time to instantiate its GUI, so that
calls the edit_svg() are slow to
On Fri, Sep 10, 2010 at 9:41 AM, Terry Brown terry_n_br...@yahoo.com wrote:
On Fri, 10 Sep 2010 06:20:40 -0700 (PDT)
Edward K. Ream edream...@gmail.com wrote:
Performance of post production (inkscape) code is not good. I'll see
where the bottlenecks are.
I think Inkscape takes an
On Fri, 10 Sep 2010 10:01:09 -0500
Kent Tenney kten...@gmail.com wrote:
On Fri, Sep 10, 2010 at 9:41 AM, Terry Brown terry_n_br...@yahoo.com wrote:
I think Inkscape takes an annoyingly long time to instantiate its GUI, so
that calls the edit_svg() are slow to get started. I'd assume
Perhaps you'd like to get rid of camelCase while you are at it?
--
Sent from my Nokia N900
- Original message -
On Sep 10, 7:13 am, Ville M. Vainio vivai...@gmail.com wrote:
Why not move registerHandler to g?
I may have replied privately. In any case, this is a great idea,
On Fri, Sep 10, 2010 at 4:26 PM, Terry Brown terry_n_br...@yahoo.com wrote:
pep 8 work. What a great way to waste time and insert bugs.
pep 8 is actively evil unless there are reliable automatic tools in place.
I'm thinking Ville just meant in the name of the new not previously existing
On Thu, Sep 9, 2010 at 2:40 AM, Edward K. Ream edream...@gmail.com wrote:
All this is geared towards slideshows, believe it or not :-)
Technical term is yak shaving:
http://en.wiktionary.org/wiki/yak_shaving
--
Ville M. Vainio @@ Forum Nokia
--
You received this message because you are
event, I'll be working on leoPlugins.py and the screenshots plugin today.
Edward
P.S. I do not intend to do this now, but a proper plugins controller
makes it possible that all of Leo's source files could eventually be
treated like plugins, as in Eclipse.
EKR
--
You received this message
On Sep 9, 7:02 am, Edward K. Ream edream...@gmail.com wrote:
I'll be working on leoPlugins.py and the screenshots plugin today.
The plugins work is complete at the trunk at rev 3363.
This involved a *lot* of work, most of which I envisioned when I
initially objected to making screenshots.py
On Sep 9, 11:29 am, Edward K. Ream edream...@gmail.com wrote:
In other words, there are two protocols for loading a plugin:
1. At Leo's load time: init is called, and other events get generated
as usual. onCreate is **not** called automatically.
2. After Leo's load time: both init
On Sep 9, 11:32 am, Edward K. Ream edream...@gmail.com wrote:
**Important**: the second protocol only happens if we are call
g.loadOnePlugin instead of g.app.pluginsController.loadOnePlugin (!!!)
Which reminds me. pc.loadOnePlugin could try to choose whether to
call onCreate based on
creating a few g.command entries should be
enough for a plugin like this.
--
Ville M. Vainio @@ Forum Nokia
--
You received this message because you are subscribed to the Google Groups
leo-editor group.
To post to this group, send email to leo-edi...@googlegroups.com.
To unsubscribe from
On Thu, Sep 9, 2010 at 12:09 PM, Ville M. Vainio vivai...@gmail.com wrote:
What's your reason for dealing with all this complex stuff? What kind
of integration are you trying to accomplish?
The complexity behinds the scenes makes things a lot simpler for the
user. It makes the following
On Thu, Sep 9, 2010 at 8:55 PM, Edward K. Ream edream...@gmail.com wrote:
On Thu, Sep 9, 2010 at 12:09 PM, Ville M. Vainio vivai...@gmail.com wrote:
What's your reason for dealing with all this complex stuff? What kind
of integration are you trying to accomplish?
The complexity behinds the
On Thu, Sep 9, 2010 at 1:00 PM, Ville M. Vainio vivai...@gmail.com wrote:
So you are basically saying that [sc].loadOnePlugin was broken previously?
Yes. It had defects. It still does, to a lesser extent, but
g.loadOnePlugin masks them.
Furthermore, it had been on my list for a long time to
Leo outlines have been opened.
This isn't a ridiculous assumption, but it causes problems when we
want to load a plugin after Leo's startup code has finished.
In hindsight, we would want a more flexible approach. Each plugin
might be expected to support onLoad and onCreateLeoOutline entry
points
On Thu, Sep 9, 2010 at 4:03 PM, Edward K. Ream edream...@gmail.com wrote:
In hindsight, we would want a more flexible approach. Each plugin
might be expected to support onLoad and onCreateLeoOutline entry
points. Either could be optional: some plugins don't care about
outline hooks
message -
On Thu, Sep 9, 2010 at 4:03 PM, Edward K. Ream edream...@gmail.com
wrote:
In hindsight, we would want a more flexible approach. Each plugin
might be expected to support onLoad and onCreateLeoOutline entry
points. Either could be optional: some plugins don't care about
After all the discussion, the packaging doesn't feel right in
leoRst.py. I'll create a screenshot plugin soon.
This plugin will be official' in the sense that it will always be
available by default. The plugin will probably set c.inkscapeCommands
or maybe c.screenshotCommands.
I had forgotten
Thanks for making the rigth decision :-)
On Wed, Sep 8, 2010 at 7:13 PM, Edward K. Ream edream...@gmail.com wrote:
Another factor is that I'm using the decorator @g.command('command-
name') to create commands, and this decouples the command from Leo's
core. The more I use this pattern, the
, there is a bit of a problem with g.command in a plugin.
If we put the function at the top level, it will always be defined,
even if the plugin doesn't load. For this reason, I am using
c.k.registerCommand in the top-level onCreate function.
Edward
--
You received this message because you are subscribed
On Wed, Sep 8, 2010 at 8:07 PM, Edward K. Ream edream...@gmail.com wrote:
Ironically, there is a bit of a problem with g.command in a plugin.
If we put the function at the top level, it will always be defined,
even if the plugin doesn't load. For this reason, I am using
Well, the answer
On Wed, Sep 8, 2010 at 12:20 PM, Ville M. Vainio vivai...@gmail.com wrote:
Ironically, there is a bit of a problem with g.command in a plugin.
If we put the function at the top level, it will always be defined,
even if the plugin doesn't load.
Well, the answer is to not put it at toplevel
On Sep 8, 4:37 pm, Edward K. Ream edream...@gmail.com wrote:
Yes, defining the commands inside the init function will work.
Done at the trunk at rev 3354. In fact, the top-level defines are
simple and good, as you can see for yourself.
At present the inconveniences of using a plugin
On Sep 8, 6:40 pm, Edward K. Ream edream...@gmail.com wrote:
Yes, defining the commands inside the init function will work.
Done at the trunk at rev 3354. In fact, the top-level defines are
simple and good, as you can see for yourself.
Notes:
- The plugin docstring does show up
On Sep 8, 6:40 pm, Edward K. Ream edream...@gmail.com wrote:
leoPlugins.py [is] a sewer: it's nothing but functions and globals.
Rev 3358 completes a grand rewrite of leoPlugins.py. The highlights:
1. Early in the startup process, leo calls leo.core.leoPlugins.init(),
which in turn sets
I got the last version of leo, using Bazaar, and found a bug. Here is
the file abbrev.txt:
--
eachwhile=while(my ($key, $value) = each(%))\n{\n}\n
Gives an error:
exception executing command
Traceback (most recent call
On Thu, Sep 2, 2010 at 1:01 AM, Ivanov Dmitriy usr...@gmail.com wrote:
\leoEditCommands.py, line 620, in readAbbreviations
a, b = x.split('=', 1)
ValueError: too many values to unpack
My apologies. The fix, and a comprehensive new unit test, is on the
trunk at rev 3315.
Please report any
On Sep 1, 7:51 pm, Edward K. Ream edream...@gmail.com wrote:
This will conclude work on abbreviations unless real bugs are found.
OMG. How did I ever live without abbreviations :-)
Rev 3318 fixes some annoyances that quickly became apparent. Here is
the checkin log:
QQQ
Improved
On Thu, Sep 2, 2010 at 8:57 AM, Edward K. Ream edream...@gmail.com wrote:
Rev 3318 fixes some annoyances that quickly became apparent. Here is
the checkin log:
I forgot to mention that Leo will no longer complain if a new
definition overrides an old definition with exactly the same
I found abbrevCommandsClass (test) in the file. And there was a help:
type some text, set its abbreviation with Control-x a i g, type the
text for abbreviation expansion
type Control-x a e ( or Alt-x expand-abbrev ) to expand abbreviation
type Alt-x abbrev-on to turn on automatic abbreviation
On Wed, Sep 1, 2010 at 2:50 AM, Ivanov Dmitriy usr...@gmail.com wrote:
I found abbrevCommandsClass (test) in the file. And there was a help:
Thanks for this report. I'm not aware that anyone is actually using
these. Iirc, the code may not be functional.
Your timing is perfect. I've been
Is it possible to make them work as in emacs. I write an abbreviation,
press space and it's being automatically substituted, if the abbrev
mode is on? It seems, that the abbreviations are loaded from the file
correctly - I tested that. The file is being read line by line:
for x in f:
On Wed, Sep 1, 2010 at 7:36 AM, Edward K. Ream edream...@gmail.com wrote:
Your timing is perfect. I've been thinking of taking a few hours off
to add another kind of abbreviation. Before doing so, it would seem
prudent to see if the present code can be made to work.
Rev 3305 gets the basics
901 - 1000 of 1500 matches
Mail list logo
