by fixing only one bug at a time. The
problem is that I'm not a real vim user so that I can't really test the vim
modes code as it should be tested.
Edward
--
Edward K. Ream email: [EMAIL PROTECTED]
Leo: http
On Wed, Jun 4, 2008 at 10:53 AM, TL [EMAIL PROTECTED] wrote:
Repeat last command using the period
Binding keys within nodes:
Some commands can be easily repeated by having the command's mode
bind itself to the period key. This is not currently working.
I doubt this will ever work. Due
On Wed, Jun 4, 2008 at 2:50 PM, Armando Rowe [EMAIL PROTECTED] wrote:
I needed to upload a business document to Leo, found plugin
paste_as_headlines and created paste_as_new_node to facilitate
converting the whole document into a tree. It's been working wonders
for me.
Do you accept
On Wed, Jun 4, 2008 at 12:41 PM, TL [EMAIL PROTECTED] wrote:
Edward, please consider adding the following to your high-priority
ToDo list for Leo.
Currently, Leo has some basic support for recording schedule estimates
and actuals using the Cleo plugin. Unfortunately, for many of the
@file
On Wed, Jun 4, 2008 at 9:03 PM, TL [EMAIL PROTECTED] wrote:
I hacked k.endMode so it restores focus.
Thanks Edward,
It looks like your change did the job.
Good. On to the next item. BTW, support for 'dot' will wait until b2.
Edward
On Thu, Jun 5, 2008 at 5:28 AM, derwisch
[EMAIL PROTECTED] wrote:
...sometimes I just need a documented set of
requirements, together with the code to implement them, printed out,
read by somebody else and signed.
...I would very much like to have a linearized document
that has all
On Wed, Jun 4, 2008 at 4:12 PM, Terry Brown [EMAIL PROTECTED] wrote:
I've just pushed a more polished version of my @menuat @settings
directive to the menuat branch.
I had forgotten about this work. It would seem to be another solution to
Kent's problem of adding small changes to menus
On Thu, Jun 5, 2008 at 3:30 AM, zpcspm [EMAIL PROTECTED] wrote:
I am still having problems when trying to reproduce the plugin example
from the docs.
There was a bug in the plugin which has been fixed on the trunk (in
leo\plugins\examples).
Change g.makeScriptButton to
On Thu, Jun 5, 2008 at 8:51 AM, Terry Brown [EMAIL PROTECTED] wrote:
Perhaps just throw in a os.path.realpath()?
I didn't know about the two-names-for-the-same-path problem. I'll put the
fix in immediately: it will require a new g.os_path_realpath method so as to
handle unicode properly in
On Thu, Jun 5, 2008 at 9:00 AM, Edward K. Ream [EMAIL PROTECTED] wrote:
On Thu, Jun 5, 2008 at 8:51 AM, Terry Brown [EMAIL PROTECTED]
wrote:
Perhaps just throw in a os.path.realpath()?
I didn't know about the two-names-for-the-same-path problem. I'll put the
fix in immediately
On Jun 5, 6:37 am, Edward K. Ream [EMAIL PROTECTED] wrote:
On Wed, Jun 4, 2008 at 9:03 PM, TL [EMAIL PROTECTED] wrote:
I hacked k.endMode so it restores focus.
Thanks Edward,
It looks like your change did the job.
Good. On to the next item.
When I wrote this, I was thinking
On Thu, Jun 5, 2008 at 10:04 AM, TL [EMAIL PROTECTED] wrote:
Zapped text to clipboard (Moderate problem / Easy to fix?):
The zap-to-character command does not copy the zapped text to the
clipboard. This prevents many of vi's delete or yank commands from
being followed by a paste command.
On Thu, Jun 5, 2008 at 9:26 AM, Terry Brown [EMAIL PROTECTED] wrote:
oh, wait, looks like it's reading the same .leoRecentFiles.txt twice...
probably not that important, but if you want to squash that while
you're there...
The same kind of fix is on the trunk now, r502. Please let me know
On Thu, Jun 5, 2008 at 10:22 AM, TL [EMAIL PROTECTED] wrote:
Enable binding functions to a number key
Vi's ability to specify the number of times to execute a command or
which occurrence of a text object to act on could be supported if the
number keys 0-9 could be bound to a function.
On Thu, Jun 5, 2008 at 11:52 AM, Terry Brown [EMAIL PROTECTED]
wrote:
I run this script from a button:
...
others = [i.copy() for i in p.siblings_iter()
if i.headString().startswith(bn+'.')]
This is wrong: positions become invalid after changing the outline.
Edward
On Jun 5, 11:19 am, Edward K. Ream [EMAIL PROTECTED] wrote:
BTW, I added yet another callback in tree.setCanvasBindings to handle
tag_bind, but it looks like all or most calls to w.tag_bind(...) should be
changed to c.tag_bind(w,...).
The fix in on the trunk, rev 507. All unit tests pass
On Thu, Jun 5, 2008 at 1:34 PM, Terry Brown [EMAIL PROTECTED] wrote:
but only because it's careful to only use positions that occur before
(in document order) points where changes have been made.
...
Is that the best way to address these things? It seems to add
complexity beyond the
On Thu, Jun 5, 2008 at 2:50 PM, Terry Brown [EMAIL PROTECTED] wrote:
I still seem to be not getting updates from cleo's right click on an
icon box context menu, and script buttons.
I'll look into it.
I'm still using the begin/endUpdate try/finally pattern, should I
switch to something
On Thu, Jun 5, 2008 at 2:31 PM, Terry Brown [EMAIL PROTECTED] wrote:
I think the complexity is, in fact, part of the problem domain. You
simply must be aware of whether positions are valid or not.
Agreed given the way positions work. Seems this sort of thing is
easier in some of the XML
On Sun, Jun 8, 2008 at 8:23 AM, zpcspm [EMAIL PROTECTED] wrote:
Does anyone have any idea why LEO segfaults
Since leo is just a python script, it can't segfault itself. It's the
python binary or one of its libraries. I would try to run the python
interpreter from gdb and get a backtrace
On Jun 8, 5:32 am, bobjack [EMAIL PROTECTED] wrote:
I apologize for these problems and will do my best to fix them as soon
as possible.
I just pushed a change to tkTree.setCanvasBindings that may be related
to this. The 'event' arg in the callback was mistakenly bound to the
'event' arg
On Jun 9, 12:09 pm, Terry Brown [EMAIL PROTECTED] wrote:
On Mon, 9 Jun 2008 09:08:42 -0700 (PDT)
Edward K. Ream [EMAIL PROTECTED] wrote:
On Jun 8, 5:32 am, bobjack [EMAIL PROTECTED] wrote:
Just re-enabled rclick and I'm no longer seeing traceback on cleo
context menus. That was my
On Jun 9, 4:13 pm, Ville M. Vainio [EMAIL PROTECTED] wrote:
On Fri, Jun 6, 2008 at 5:36 PM, Edward K. Ream [EMAIL PROTECTED] wrote:
P.S. It is my present opinion that wxWidgets is not capable of
supporting a proper gui plugin for Leo I won't reject such a plugin--
in fact I would love
On Jun 9, 4:39 pm, Ville M. Vainio [EMAIL PROTECTED] wrote:
On Tue, Jun 10, 2008 at 12:13 AM, Ville M. Vainio [EMAIL PROTECTED] wrote:
I am asking this because I'm wondering about the feasibility of pyqt
plugin... and I thought lots of stuff could be simpler. The tree view
for example,
On Jun 9, 6:07 pm, Pieter [EMAIL PROTECTED] wrote:
Hi,
I once thought about a PyQt frontend also. However, when I looked into
the Leo PyGTK code a few months ago, it seemed that the current GUI
code does not follow a Publisher - Subscriber pattern, or something
remotely related. It seemed
On Jun 10, 4:04 am, Ville M. Vainio [EMAIL PROTECTED] wrote:
On 6/10/08, Pieter [EMAIL PROTECTED] wrote:
Yeah, it (the gtk plugin) didn't seem to use publish-subscribe and MVC
structure (for outline tree view), which kind of raised some concerns
for me about how easy / fun it would be.
On Jun 10, 4:33 am, bobjack [EMAIL PROTECTED] wrote:
We just treat Leo itself as a model and create
some kind of UI on top of that. E.g. key bindings would not be
immediately set like they should, but it could lead to cleanups and
removal of assumptions on many fronts. What I'm talking
On Jun 10, 9:36 am, Edward K. Ream [EMAIL PROTECTED] wrote:
The task
is not to duplicate the Tk code, which is *extremely* complex. The
task is to implement c.frame.tree.redraw_now. How you do that is up
to you. If the gui supports a capable tree widget, the obvious first
choice
On Jun 10, 10:07 am, bobjack [EMAIL PROTECTED] wrote:
I only use a tiny subset of Leo myself and have removed many items
from the main menu.
The complexity of Leo can indeed be very intimidating. All that tangle
and literate programming stuff does my head in, I nearly passed Leo by
On Jun 10, 10:17 am, Kent Tenney [EMAIL PROTECTED] wrote:
I have trouble grokking Leo's position on the
monolithic - componentized scale.
From my point of view, Leo has remained remarkably stable over these
last 12 years of so. The mvc architecture is unchanged. More
important, what Leo has
On Jun 10, 10:46 am, Kent Tenney [EMAIL PROTECTED] wrote:
Edward, surely you don't have a problem with
MORE FEATURES!
(pause)
TOO MANY FEATURES!
:-]
Of course not. Talking to you, Kent, is always a pleasure :-) And
conflicts and confusions are often the spur to new inventions...
On Tue, Jun 10, 2008 at 3:02 PM, jkn [EMAIL PROTECTED] wrote:
Hi Edward
out of interest, do you know which version of wxWidgets you last
looked at?
No I don't. It was probably over a year ago.
Regardless, all this interest activity on the GUI side of things is
very interesting to
On Tue, Jun 10, 2008 at 11:50 PM, Kayvan A. Sylvan [EMAIL PROTECTED]
wrote:
Clicking on any node in the headings pane that has child nodes
produces an error like this one:
Sorry about that. The fix is on the trunk.
All unit tests pass, but then they did before. I might add another unit
On Jun 11, 8:22 am, Edward K. Ream [EMAIL PROTECTED] wrote:
On second thought, c.redraw_now indeed probably should call c.outerUpdate.
The little mystery of the missing redraw has been solved: cleo uses
aMenu.add_command to invoke several commands. This is another way
into code
On Wed, Jun 11, 2008 at 8:52 AM, tfer [EMAIL PROTECTED] wrote:
I'm tempted to take a stab at one of the side gui possibilities
Edward's work opened up, that of using emacs as the gui to a pymacs
controlled leobridge instance.
You should be able to take emac's outline mode and use it as the
On Jun 11, 8:44 am, Edward K. Ream [EMAIL PROTECTED] wrote:
The little mystery of the missing redraw has been solved: cleo uses
aMenu.add_command to invoke several commands. This is another way
into code. add_command is used by several plugins, so I suppose
changing m.add_command
On Wed, Jun 11, 2008 at 12:07 PM, Terry Brown [EMAIL PROTECTED]
wrote:
I just committed cleo.py with a couple of c = self.c needed for
c.add_command to work.
Thanks.
Edward
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the
On Thu, Jun 12, 2008 at 4:55 AM, bobjack [EMAIL PROTECTED] wrote:
Another minor bug is that when ctrl-shift-p is used to reformat a
paragraph, all the coloring disappears.
Thanks for this. The fix is on the trunk.
This is the kind of nit that determines whether the new drawing code is, in
On Thu, Jun 12, 2008 at 4:55 AM, bobjack [EMAIL PROTECTED] wrote:
On Jun 10, 11:02 am, bobjack [EMAIL PROTECTED] wrote:
1: When you open a new leo frame from the menu, the new frame only has
a single New Headline node. When you click that node another New
Headline node appears. If you
On Thu, Jun 12, 2008 at 8:26 AM, bobjack [EMAIL PROTECTED] wrote:
1: When you open a new leo frame from the menu, the new frame only
has
a single New Headline node. When you click that node another New
Headline node appears. If you edit the first New Headline node the
On Thu, Jun 12, 2008 at 8:14 AM, bobjack [EMAIL PROTECTED] wrote:
On Jun 11, 3:51 pm, Edward K. Ream [EMAIL PROTECTED] wrote:
On Jun 11, 8:44 am, Edward K. Ream [EMAIL PROTECTED] wrote:
The little mystery of the missing redraw has been solved: cleo uses
aMenu.add_command to invoke
On Thu, Jun 12, 2008 at 7:26 AM, derwisch
[EMAIL PROTECTED] wrote:
After reading the docs of the rst plugin and a bit of playing I found
that the code-mode and show-doc-parts-as-paragraphs options make Leo
do almost exactly what I want.
Glad to hear it. rst3 can do almost anything as it
On Jun 12, 10:07 am, Edward K. Ream [EMAIL PROTECTED] wrote:
rClick is broken by this.
Sorry about that. I could have sworn I checked rClick specifically. I'll
fix this today. No need to revert anything.
The fix is on the trunk. All unit tests pass. Please let me know how
it works
On Fri, Jun 13, 2008 at 4:39 AM, derwisch
[EMAIL PROTECTED] wrote:
def collectRules(p):
[node for node in p.self_and_subtree_iter() if Cleo.getat(node.v,
'archetype') == 'Logic']
This return None because you forgot the 'return' statement.
Edward
On Mon, Jun 16, 2008 at 4:14 AM, bobjack [EMAIL PROTECTED] wrote:
I'm not familiar with tag_bind, maybe the add=None fix should be
applied to that as well?
Let's not touch tag_bind now.
Edward
--~--~-~--~~~---~--~~
You received this message because you are
On Jun 16, 8:51 am, Edward K. Ream [EMAIL PROTECTED] wrote:
You were wise not to attempt a specific fix.
Actually, the fix involved creating new callbacks in several plugins
where there are calls of the form:
b.configure(command=command)
In other words, a common pattern is:
b
On Fri, Jun 13, 2008 at 8:38 AM, Kent Tenney [EMAIL PROTECTED] wrote:
Why is the code very complex?
It's complex because there are lots of special cases. This is often the
case with code that looks simple. In this case, the special cases involve
issues such as the following:
- How to
On Fri, Jun 13, 2008 at 11:09 AM, Terry Brown [EMAIL PROTECTED]
wrote:
My active_path plugin is working quite well now. I'll commit it to
the trunk, it's only a plugin so it won't do anything unless you enable
it (active_path.py).
Very interesting. I'll add @thin active_path.py to
On Mon, Jun 16, 2008 at 9:38 AM, bobjack [EMAIL PROTECTED] wrote:
Doh! Yes of course! Thank you.
I added the *args arg to both c.bind and c.bind2. It's now on the trunk.
With this change, c.bind and c.bind2 are identical. If this change actually
works I'll eventually change all calls to
Afaik all vim-like patches have been applied to the latest trunk:
Headline pane:
- (Done earlier) Prevent -- exit-named-modes from switching focus
to the Body pane.
Removed 'c.frame.log.deleteTab('Mode') from endMode
Body pane:
- (Done today) Enable search for 'space' character in text
On Tue, Jun 17, 2008 at 8:00 AM, TL [EMAIL PROTECTED] wrote:
I'm trying to diff two Leo files using Vim's diff capability.
However, it appears that the two Leo files have their internal
sentinal blocks ordered differently even though the outline hierarchy
is the same. Does this happen? If
On Tue, Jun 17, 2008 at 7:11 AM, TL [EMAIL PROTECTED] wrote:
Hi Yarko,
Thanks for the bug report. What you describe is a known problem.
Yesterday I found something that could cause no end of confusion. In
leoSettings.leo there was a node:
@settings--Keyboard shortcuts--@keys EKR
In the course of working with the new vim bindings/modes I have
changed how Leo handles @shortcuts nodes as follows:
1. Binding a command to None has no effect whatever. Such bindings
are now useful only to indicate to the check-bindings script (in
leoSettings.leo) that a command exists.
2.
On Wed, Jun 4, 2008 at 9:03 PM, TL [EMAIL PROTECTED] wrote:
2. Editing headlines within modes (Major problem / Difficult to fix?):
Commands that modify or select headline text correctly when bound
directly to a key will, when executed from within a mode bound to that
same key, modify or
This discussion of g.os_path_x vs. os.path_x is off the mark.
The g.os_path_x wrappers exists for only one reason: to handle unicode
filenames properly. In all other respects g.os_path_x and os.path_x are
identical. Indeed, the g.os_path_x methods call the os.path methods.
Edward
I'm just about at my wits end concerning Tk key handling. Maybe
that's a good thing: it may be time to try some new things.
At present, I do not recommend using the vim bindings. The bindings
themselves are fine: the problem is elsewhere--either Leo or Tk.
At present, it appears that
On Thu, Jun 19, 2008 at 4:20 AM, bobjack [EMAIL PROTECTED] wrote:
I apologize profusely for this very serious error which must have
caused a lot of problems and unnecessary hard work for Edward and
others.
Don't worry about it. I doubt this had much effect on the work I am doing.
Edward
On Thu, Jun 19, 2008 at 7:00 AM, bobjack [EMAIL PROTECTED] wrote:
I'm sorry I appear to have trashed the trunk.
Guess I'm having a bad hair day :(
In the future, be sure to run all unit tests before any push. Having all
unit tests pass guarantees that a) Leo will most likely continue to
On Wed, Jun 18, 2008 at 3:48 PM, Terry Brown [EMAIL PROTECTED]
wrote:
Whoops, I now find my second approach doesn't work, so back to the
original question, what's the neatest way to remove nodes matching a
criteria?
The only good answer is: carefully. The problem is that deleting a node
On Wed, Jun 18, 2008 at 12:20 PM, TL [EMAIL PROTECTED] wrote:
I now have some local code which binds keys to the do-nothing
command. For example, do-nothing !tree = Ctrl-a. It seems to have
an advantage over using the ! kill approach in that it retains
support for targeting the outline or
On Wed, Jun 18, 2008 at 3:49 PM, Kent Tenney [EMAIL PROTECTED] wrote:
I just created a node
@file-nosent buildout/README.txt
(README.txt is a rst file)
the file buildout/README.txt exists, I expected it to
be loaded into the body of the @file-nosent node,
It is your expectations, not
On Thu, Jun 19, 2008 at 12:37 PM, TL [EMAIL PROTECTED] wrote:
it should be possible to define the needed commands using @command nodes.
Any documentation on @command nodes? I can't find any.
The best documentation is in the Plugins:Scripting menu, which is only
available if
On Thu, Jun 19, 2008 at 12:27 PM, Kent Tenney [EMAIL PROTECTED] wrote:
It is your expectations, not Leo, that are faulty. Leo can never read
@nosent nodes:
Why not?
Because there are no sentinels in the file! Without sentinels, your options
are:
1. Use @auto to get the file.
2. Use
On Fri, Jun 20, 2008 at 7:34 AM, TL [EMAIL PROTECTED] wrote:
otoh, maybe the simplest solution would be to suppress
such complaints when binding to do-nothing. That would
indeed make !kill unnecessary.
Most binding message refer to binding keys from the do-nothing command
to the vi
On Sun, Jun 22, 2008 at 1:43 PM, zpcspm [EMAIL PROTECTED] wrote:
As a first attempt of a fix, I added the line:
s = g.toUnicode(s,encoding=g.app.tkEncoding)
to the insert-text logic. I'm not sure this will help.
I am having touble finding the proper place in the leo source.
Sorry
On Mon, Jun 23, 2008 at 4:33 AM, bobjack [EMAIL PROTECTED] wrote:
Undo appears to be broken. Any significant sequence of undo's results
in corruption. I used to use undo/redo as a sort of cheap version
control, now I hardly dare use it at all.
Can you be a bit more specific?
Edward
I am thinking it may be time to require Python 2.4. This would give
Leo access to decorators and other good features.
Does anyone have any objections to this?
Edward
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
On Mon, Jun 23, 2008 at 10:34 AM, Terry Brown [EMAIL PROTECTED]
wrote:
Would it make any sense to jump to 2.5? In other python contexts I've
been bitten by:
a = b if c else d
and
from collections import defaultdict
...but I'm thinking 2.5 is probably too rare, so 2.4 would be the
On Tue, Jun 24, 2008 at 9:14 AM, TL [EMAIL PROTECTED] wrote:
Edward,
The Vim update included an updated Chapter 22 in the user's guide.
Can you publish that to the website?
It caused a conflict, which I resolved. It's now on the trunk.
Edward
On Mon, Jun 23, 2008 at 1:18 PM, TL [EMAIL PROTECTED] wrote:
Do you plan to fix this problem for Leo 4.5 b1?
The fix is now on the trunk.
Edward
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
leo-editor group.
On Tue, Jun 24, 2008 at 8:47 AM, Edward K. Ream [EMAIL PROTECTED] wrote:
The following does not show all the problems I have been experiencing
but it does serve to show that undo/redo is broken.
It appears there is a blunder in u.undoInsertNode. I cleverly tried to
use c.deleteOutline
Something strange happened with the spelling mistake
(universallCallback). Rev 579 on the trunk corrects the spelling
(again??). And there is code that I don't understand in
universalCallback, and it may have been reverted somehow also.
Please check this code, bobjack. Thanks.
Edward
On Jun 24, 10:48 am, Edward K. Ream [EMAIL PROTECTED] wrote:
It appears there is a blunder in u.undoInsertNode.
The problem was much more interesting than that, and happily much
easier to fix. The fix is on the trunk at rev 579.
It turns out that a call to c.redraw_now must be made
On Mon, Jun 23, 2008 at 10:15 AM, Terry Brown [EMAIL PROTECTED]
wrote:
Minor nit - insert-file to load a file into a node, text appears in the
body pane. Without doing anything else to the body pane click on
another node. Inserted text is lost - body for node is empty. As long
as you move
On Mon, Jun 23, 2008 at 11:20 AM, Terry Brown [EMAIL PROTECTED]
wrote:
c.beginUpdate()
try:
add / change icons on some nodes
c.setChanged(True)
finally:
c.endUpdate()
seems not to give a redraw *after* a script button is pressed.
It does give one before the action is taken, so
On Tue, Jun 24, 2008 at 2:09 PM, Terry Brown [EMAIL PROTECTED]
wrote:
But the main idea is that @thin trees have no descendant v
elements: Leo builds the outline solely from the thin derived file.
Ok, that makes sense. But if you wanted to store attributes, wouldn't
it just be a matter
On Tue, Jun 24, 2008 at 11:29 AM, Terry Brown [EMAIL PROTECTED]
wrote:
The @ignore docs. are broken:...
But @ignore appears to be valid and useful in subtrees of @nosent files.
Interesting. It took 30 minutes to discover that @ignore 'works' while
writing @others nodes. Outside @others it
On Tue, Jun 24, 2008 at 11:52 AM, Terry Brown [EMAIL PROTECTED]
wrote:
p.s. when I switched to @nosent for this file I found the probably
seemed to persist, but I got an enigmatic
dubious brackets in Left column
dubious brackets in Right column
Leo issues the 'dubious brackets' message
Most afternoons I do p.t. for an arthritic shoulder in a warm-water
pool. For the last two sessions my subconscious has been screaming at
me. It probably has to do with recent questions and remarks about
sentinels, as well as comments denoting headlines in @nosent trees.
Today I had some
On Jun 24, 5:46 pm, Edward K. Ream [EMAIL PROTECTED] wrote:
Today I had some thoughts that arose (indirectly) from Bernhard
Mulder's shadow plugin.
Surprisingly, another important source for this idea was the idea of
writing headline comments for @nosent nodes. These comments might
On Jun 24, 6:00 pm, Edward K. Ream [EMAIL PROTECTED] wrote:
Today I had some thoughts that arose (indirectly) from Bernhard Mulder's
shadow plugin.
On sleeping on this queston, I think the Aha really means that I
should start using the shadow plugin. I *really* do not want to give
up
On Tue, Jun 24, 2008 at 3:48 PM, Terry Brown [EMAIL PROTECTED]
wrote:
This has taken me a bit to pin down, but here we go.
This is a nasty one. The problem is in tkTree.yoffsetTree. The comparison
p1 == p2 fails because the childIndex entries in p1.stack are different from
p2.stack. As a
On Wed, Jun 25, 2008 at 11:01 AM, Kent Tenney [EMAIL PROTECTED] wrote:
So, I see it as a matter not of up/down on sentinels, but a call for
reworking configuration to the point where there exists a @setting::
@bool use_sentinels
It may be that enabling the shadow plugin would be equivalent
On Jun 25, 11:54 am, Edward K. Ream [EMAIL PROTECTED] wrote:
This is a nasty one. The problem is in tkTree.yoffsetTree. The comparison
p1 == p2 fails because the childIndex entries in p1.stack are different from
p2.stack. As a result, the moved node isn't found and a way-too-big offset
On Thu, Jun 26, 2008 at 10:06 AM, TL [EMAIL PROTECTED] wrote:
In summary, it appears that any changes to a node's headline are not
placed in the edit history used by the undo command until after
another node has been selected.
Thanks for this report. I'll put it on the list for b2.
On Thu, Jun 26, 2008 at 11:30 AM, Terry Brown [EMAIL PROTECTED]
wrote:
To be as versatile a tool as possible it seems to me that Leo needs to
be able to select and operate on groups of nodes. I've seen the
groupOperations.py plugin, and it's ok, but I don't really think it
addresses the
On Fri, Jun 27, 2008 at 6:22 AM, Kent Tenney [EMAIL PROTECTED] wrote:
If I change a headline only, Leo closes without warning to save.
The fix is on the trunk, rev 592.
Edward
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the
On Thu, Jun 26, 2008 at 4:59 PM, Terry Brown [EMAIL PROTECTED]
wrote:
But Move would be trickier of course, given the rules about not being
your own ancestor. So I guess the polite way would be to attempt to
move all the nodes selected to the target position, and if it fails,
abort and do
Leo 4.5 beta 1 is now available at:
http://sourceforge.net/project/showfiles.php?group_id=3458package_id=29106
The highlights of Leo 4.5:
--
- A major revision of Leo's node structures, compatible with so-called
unified nodes.
- A major revision of Leo's key-handling
Now that b1 is out the door it is time to complete the transition to
the new drawing code. I have just created the redraw branch on
launchpad. I'll make these changes there:
1. Remove the old drawing code and the g.newDrawing switch. Only the
new drawing code will remain.
2. Change
On Jun 28, 11:39 am, Edward K. Ream [EMAIL PROTECTED] wrote:
In short, the drawing branch will be the scene of some experimentation :-)
It turns out that replacing::
c.beginUpdate()
try:
code
finally:
c.endUpdate()
with::
code
c.redraw()
c.update()
suffices
be to use:
@bool useTextMinibuffer = True
I would have sworn that I removed the option (and code) to use a Tk.Label
rather than a Tk.Text widget, but apparently not. Is there any particular
reason you want a Tk.Label?
Edward
Edward K
On Sat, Jun 28, 2008 at 7:06 PM, wgw [EMAIL PROTECTED] wrote:
With an output node like this:
@nosent output.htm
StartnodeFinish
.node
Bar
(i.e. using nosent, with a node that is Bar, and the main
contents StartnodeFinish)
The output.htm file produced has a spurious space:
On Sat, Jun 28, 2008 at 8:02 PM, Terry Brown [EMAIL PROTECTED]
wrote:
Will the new komodo completion code close XML elements? Is that still
on the list?
It's a good idea. In general, I think one of the biggest wow factors in
any editor is the quality of the text that can be inserted
On Sat, Jun 28, 2008 at 2:19 PM, Terry Brown [EMAIL PROTECTED]
wrote:
On Sat, 28 Jun 2008 12:15:14 -0700 (PDT)
Edward K. Ream [EMAIL PROTECTED] wrote:
code
c.redraw()
c.update()
So why both?
It turns out to be the simplest course, but see significant caveats below
On Jun 29, 10:15 am, Edward K. Ream [EMAIL PROTECTED] wrote:
As I write this, I am quite tempted to get rid of the explicit calls to
c.update, and live with the more complex binding code.
Perhaps it is obvious, but eliminating explicit calls to c.update
eliminates the need to distinguish
On Mon, Jun 30, 2008 at 5:05 AM, Bruce Wang [EMAIL PROTECTED] wrote:
the full trackback is a little different from what you'd guessed:
Plugins disabled: use_plugins is 0 in a leoSettings.leo file.
Traceback (most recent call last):
File /usr/bin/leo, line 8, in module
On Sun, Jun 29, 2008 at 3:06 PM, wgw [EMAIL PROTECTED] wrote:
Thanks for the tip.
My solution was to set @string trailing_body_newlines = zero
And, for good measure: @bool force_newlines_in_at_nosent_bodies =
False
That does the trick for me.
Glad to hear it. I certainly don't
On Mon, Jun 30, 2008 at 10:02 AM, Kent Tenney [EMAIL PROTECTED] wrote:
You sometimes mention your todo schedule in emails, but
I have trouble remembering what projects are in what state.
If there were an actual list, I think it would be useful.
The to-do list is in leoPy.leo, in the node
A few days ago I thought I was running test code from the 'redraw'
branch, but actually most imports got resolved to the 'trunk' branch.
Clearly, site.py was adding trunk's path to sys.path. My first hack
was simply to remove this path by brute force.
Today I got around to adding traces to
301 - 400 of 19883 matches
Mail list logo
