Running the latest trunk with no user key bindings (myLeoSettings.leo
file not used) shows the following behavior:
If, while editing a node (node in Insert state), an undo operation
is attempted, the undo will ignore any changes since the Insert state
was entered and, instead, undo the last
Running the latest trunk with the Vim key bindings shows the following
behavior:
Note: all steps below should leave current node in the Command state
(light blue background)
1. Select a node
2. Delete a character ('x' key)
! Undo menu item dimmed
3. Go to next node ('Ctrl-J' key)
! Undo
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 Thu, 26 Jun 2008 11:37:32 -0500
Edward K. Ream [EMAIL PROTECTED] wrote:
The simplest thing that could possibly work is to mark nodes
(possibly in a way distinct from standard marks) and then support
commands to operate on such marked nodes. Say commands such as:
clone-marked-nodes,
What limitations would you put on the node's that could be
simultaneously selected? Would they all have to have a common parent
node? If not, what would Leo do with a paste of nodes from different
parents?
TL
--~--~-~--~~~---~--~~
You received this message
On Thu, 26 Jun 2008 14:42:30 -0700 (PDT)
TL [EMAIL PROTECTED] wrote:
What limitations would you put on the node's that could be
simultaneously selected?
None... which is already the case with nodes that can be simultaneously
marked, of course.
Would they all have to have a common parent
