Just noticed this vim-ish anomoly:
Body pane, command state, this in the buffer:
-
a
b
c
--
delete a single line command 'dd' -
Position cursor on a; execute dd; single line (containing a) deleted;
Undo;
Position cursor on line after a; execute dd; two
Try adding several nodes to a new leo outline, then do sort children
on the last node. As you see, the node selection can potentially move
a long way from the original node. I first noticed this when I sorted
the children of a node near the end of a long list of nodes and the
contents of the
Instead of using os.path directly, wouldn't it be better to use
g.os_path_?
It conditions the path and path seperators for cross platform
compatibility. Remeber us poor window$ users.
Bob
--~--~-~--~~~---~--~~
You received this message because you are subscribed
Hi Yarko,
Thanks for the bug report. What you describe is a known problem. The
problem and workarounds are documented in the code within the @mode vi-
delete-line node. Unfortunately, I didn't get it into the user
documentation. Sorry about that. The problem results from the fact
that Leo's
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, 17 Jun 2008 08:47:20 -0500
Terry Brown [EMAIL PROTECTED] wrote:
os.path is OS aware... but g.os_path_ may be the better option anyway,
saves importing os etc. Of course, I hope the active_path plugin will
be able to use leo's internal @path logic when it understands nesting.
Second
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
I support removing the @mode d::Delete... you refer to. However,
it is not the cause of the delete line problem. The problem Yarko
raised is simply Leo executing the delete line code as I implemented
it. Coding the @mode functions in general is limited by a lack of
conditional branches and an
Another trivial nit - but may have to do with key binding machinery,
so I'll bring it up:
Motion in VI:
up-down-left-right work fine with k-j-h-l...
the other motions I often use are beginning / end of line, so I've
noticed
beginning = ^ works; 0 [zero] doesn't
I said it was a nit... but as
Another nit - but has to do with key binding machinery,
so I'll bring it up:
Motion in VI:
up-down-left-right work fine with k-j-h-l...
the other motions I often use are beginning / end of line, so I've
noticed
beginning (first non-blank on a line) = ^ works;
beginning of line = 0 [zero]
12 matches
Mail list logo
