Proposal: remove/improve all chapter commands

[Edward K. Ream]

If you use Leo's chapters, please read the following carefully.  Unless I hear howls of protest, I'll make the following changes. Don't panic, there will be ample time for comments.

At present, Leo's supports the following chapter-related commands:

    chapter-clone-node-to
    chapter-convert-node-to
    chapter-copy-node-to
    chapter-create
    chapter-create-from-node
    chapter-move-node-to
    chapter-remove
    chapter-rename
    chapter-select

Imo, only the chapter-select command is needed. It should be improved, as explained in point 3 below. All other commands should be removed:

1. The new chapters code dynamically updates the list of chapter names whenever the list is needed. As a result, the user can do the following commands more easily by creating, renaming, moving, copying or deleting @chapter nodes:

    chapter-convert-node-to
    chapter-create
    chapter-create-from-node
    chapter-rename
    chapter-remove commands

The old (brain dead) code needed these commands to update internal data structures. The new code updates the structures as needed.

2. Now that @chapter nodes need no longer be children of an @chapters nodes, it is easier for the user to move or clone nodes between chapters using Leo existing clone, copy-node, paste-node and especially the cffm commands.  As a result, these ridiculously clumsy commands should be retired:

    chapter-clone-node-to
    chapter-copy-node-to
    chapter-move-node-to

I wonder whether anyone actually has ever used these commands. Do you?
 
3. At present, the chapter-select uses a non-standard, clumsy, way of prompting for a chapter name. Instead, the Alt-x code should have a hook that allows the chapters code to add/remove chapter-select commands. So after <alt-x>chap<tab>, the user would see:

    chapter-select-(chapter-name-1)
    chapter-select-(chapter-name-2)

that is, the list of chapter names, in alphabetical order. As always, tab completion would allow the user to select the desired chapter quickly.

Furthermore, users should be able to bind keystrokes to these commands, even though they are created dynamically.  This may be a bit tricky to do, but it is the correct thing to do. It maintains the desired illusion of simplicity.

Summary

Imo, only the chapter-select command should remain, and it should be improved as just discussed.

Chapters are almost like hoists, with the following differences:

A. The Chapters box in the icon area.  This is useful to have even with the new chapters-select-* logic in place.

B. Selecting a chapter is not quite the same as same as hoisting an @chapters node: only the children of the @chapters node are shown. This seems dubious, but it was a requested feature.  It's not going to go away, although it could become an option.

Your comments, please, Amigos.

Edward

[Jacob Peck]

As a daily user of chapters, these changes are long overdue.  Fire away!

FWIW, the various chapter-* commands have always been an absolute pain, and as you mentioned, brain dead.  I always found myself needing a reload of my outline after serious restructuring.  Dynamic is the way to go.

-->Jake

--
You received this message because you are subscribed to the Google Groups "leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+...@googlegroups.com.
To post to this group, send email to leo-e...@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

[Edward K. Ream]

On Sun, Apr 3, 2016 at 6:45 AM, Jacob Peck <gates...@gmail.com> wrote:

As a daily user of chapters, these changes are long overdue.  Fire away!

FWIW, the various chapter-* commands have always been an absolute pain, and as you mentioned, brain dead.  I always found myself needing a reload of my outline after serious restructuring.  Dynamic is the way to go.

​Thanks for these comments!  Are you using the latest code?

Edward

[Jacob Peck]

I have not been at a computer the past few days (thankfully) but I'll definitely be pulling it tonight/tomorrow.

-->Jake

--

[john lunzer]

I fully agree. With one caveat, after the removal of :

    chapter-clone-node-to
    chapter-copy-node-to
    chapter-move-node-to

There is still a need for these generalized commands that work anywhere:

    clone-marked-here
    copy-marked-here
    move-marked-here

I find it near impossible to move multiple nodes around in Leo. I've been looking for a multi-select version of copy/cut/clone for ages, Leo should have these out of the box. Leo has clone-marked-nodes but I find it oddly inconvenient that it throws them at the end of the outline (by going down there I lose my spot in the outline, seems unnecessary). These generalized commands should behave just as copy and cut do in respect to their paste behavior. You don't really need the "-here" on the those commands but I was trying to differentiate them from the existing clone-marked-nodes. 

I think these new commands would offer a lot of flexibility and efficiency in organizing outlines (especially very large outlines). 

[Terry Brown]

On Mon, 4 Apr 2016 10:08:57 -0700 (PDT)
john lunzer <lun...@gmail.com> wrote:

> I fully agree. With one caveat, after the removal of :
>
> chapter-clone-node-to
> chapter-copy-node-to
> chapter-move-node-to
>
> There is still a need for these generalized commands that work
> anywhere:
>
> clone-marked-here
> copy-marked-here
> move-marked-here
>
> I find it near impossible to move multiple nodes around in Leo. I've
> been looking for a multi-select version of copy/cut/clone for ages,

Although it doesn't move multiple nodes in one action, this is largely
the gap the "quickmove" plugin is aimed at. You mark a destination to
receive nodes, storing them either last child or first child, then go
an apply the action to the nodes you want to move. quickmove does not
follow the moved node, so you keep you place and can quickly move
multiple nodes. There's a single keyboard based destination
available, and any number of icon bar based destinations. You can
control whether nodes are moved / copied / cloned / linked to the
destination.

Cheers -Terry

> Leo should have these out of the box. Leo has clone-marked-nodes but
> I find it oddly inconvenient that it throws them at the end of the
> outline (by going down there I lose my spot in the outline, seems
> unnecessary). These generalized commands should behave just as copy
> and cut do in respect to their paste behavior. You don't really need
> the "-here" on the those commands but I was trying to differentiate
> them from the existing clone-marked-nodes.
>
> I think these new commands would offer a lot of flexibility and
> efficiency in organizing outlines (especially very large outlines).
>
> On Sunday, April 3, 2016 at 4:59:45 AM UTC-4, Edward K. Ream wrote:
> >
> > If you use Leo's chapters, please read the following carefully.
> > Unless I hear howls of protest, I'll make the following changes.
> > Don't panic, there will be ample time for comments.
> >
> > At present, Leo's supports the following chapter-related commands:
> >
> > chapter-clone-node-to
> > chapter-convert-node-to
> > chapter-copy-node-to
> > chapter-create
> > chapter-create-from-node
> > chapter-move-node-to
> > chapter-remove
> > chapter-rename
> > chapter-select
> >

> > Imo, *only *the chapter-select command is needed. It should be

> > improved, as explained in point 3 below. All other commands should
> > be removed:
> >
> > 1. The new chapters code dynamically updates the list of chapter
> > names whenever the list is needed. As a result, the user can do the

> > following commands *more easily* by creating, renaming, moving,

> > copying or deleting @chapter nodes:
> >
> > chapter-convert-node-to
> > chapter-create
> > chapter-create-from-node
> > chapter-rename
> > chapter-remove commands
> >
> > The old (brain dead) code needed these commands to update internal
> > data structures. The new code updates the structures as needed.
> >
> > 2. Now that @chapter nodes need no longer be children of an

> > @chapters nodes, it is *easier *for the user to move or clone nodes

> > between chapters using Leo existing clone, copy-node, paste-node

> > and *especially* the cffm commands. As a result, these
> > *ridiculously clumsy* commands should be retired:

> >
> > chapter-clone-node-to
> > chapter-copy-node-to
> > chapter-move-node-to
> >
> > I wonder whether anyone actually has ever used these commands. Do
> > you?

> > 3. At present, the chapter-select uses a non-standard, *clumsy*,

> > way of prompting for a chapter name. Instead, the Alt-x code should
> > have a hook that allows the chapters code to add/remove
> > chapter-select commands. So after <alt-x>chap<tab>, the user would
> > see:
> >
> > chapter-select-(chapter-name-1)
> > chapter-select-(chapter-name-2)
> >
> > that is, the list of chapter names, in alphabetical order. As
> > always, tab completion would allow the user to select the desired
> > chapter quickly.
> >

> > Furthermore, *users should be able to bind keystrokes to these
> > commands*, even though they are created dynamically. This may be a
> > bit tricky to do, but it is the *correct *thing to do. It maintains
> > the desired *illusion* of simplicity.
> >
> > *Summary*

> >
> > Imo, only the chapter-select command should remain, and it should
> > be improved as just discussed.
> >

> > Chapters are *almost* like hoists, with the following differences:

[john lunzer]

I have used quickmove briefly. I agree that it makes working around the lack of multiple-move commands less annoying, but only slightly. The three commands that I specified are a far simpler system that utilize a core Leo concept (marking). But the truth remains, quickmove is trying to make up for something, as were the original chapter commands. This is an indication to me that a generalized set of commands is necessary.

Further investigation shows me that clone-marked-nodes is essentially clone-marked-here. Not sure why I thought it went to the bottom of the outline (oops). However, that still leaves the two missing commands copy-marked-here and move-marked-here. The additional commands should probably match the naming scheme of the current command.

However, the behavior should still match how pasting nodes currently works. The nodes should be placed at the current level if positioned with siblings. If positioned at a parent with children the new nodes should also be placed as children. This means that the behavior of clone-marked-nodes would change. It would not be a breaking change, it would just mean that a parent node wouldn't be created first. 

I also feel like this sequence is a bug:

• Mark nodes I want to clone
• execute clone-marked-nodes
• Oops, new "cloned nodes" isn't where I want it to be.
• Cut "cloned nodes"
• Past cloned nodes where I want it to be.
• Clones are no longer clones.

Why aren't my clones clones anymore? 

[Jacob Peck]

On 4/4/2016 3:03 PM, john lunzer wrote:

• Cut "cloned nodes"
• Past cloned nodes where I want it to be.
• Clones are no longer clones.

Why aren't my clones clones anymore? 

Not a bug -- paste creates copies by default.  You want 'paste-retaining-clones'.

-->Jake

[john lunzer]

In this case the clones were under a non-clone parent node. For the parent node I agree with this behavior but for it to by default wipe out all children that happen to be clones feels buggish. What is the justification for wiping out children as clones?

[Edward K. Ream]

On Mon, Apr 4, 2016 at 12:08 PM, john lunzer <lun...@gmail.com> wrote:

​> ​

I find it near impossible to move multiple nodes around in Leo.

​The new cffm command makes this a snap.  Mark the nodes you are interested in.  Do cffm.  Now you have a node containing clones of all the nodes.  Move that node where you will, or copy and paste it.

This is a major improvement to Leo's work flow.  Everyone should be aware of it.  I've just made a note to document it in Leo's tutorial, along with cff.

EKR

[john lunzer]

Ah, this is why I thought clone-marked-nodes moved it to the bottom, because cffm is similar to clone-marked-nodes but moves the node to the bottom and collapses the tree.

I disagree that this is the answer. cffm is clunky in this context, here is the sequence if I want to clone marked nodes to a specific place:

1. Mark my nodes (1 command)
2. Execute cffm (all nodes have been collapsed except for the cffm parent node) (1 command)
3. Navigate to the cffm parent node (my focus was at the first node in the outline).
4. Cut the cffm parent node (1 command)
5. Navigate to where I want the cffm node to be
6. Execute paste-retaining-clones (1 command)

Using clone-marked-nodes:

1. Mark my nodes. (1 command)
2. Navigate to where I want my marked nodes to go
3. Execute clone-marked-nodes (1 command)

Comparing the two, the first sequence requires twice as many steps and twice as many commands. In second sequence the command name tells me what I wanted to do in the first place, making it more more discoverable to new users. Additionally in the first sequence the context of my outline has been destroyed because the outline was collapsed. Edward I believe you are using cffm differently than what I am proposing which is why it doesn't work well here.

That is just for cloning, there remains no "simplest" non-work-around-plugin options for moving and copying multiple nodes, which follows the same simplest possible sequence as I have proposed. 

Leo already has clone-marked-nodes (but it doesn't follow Leo's copy/cut/paste positioning rules). My proposal: create move-marked and copy-marked and make clone-marked-nodes match their behavior. And possibly even rename clone-marked-nodes to simply clone-marked.

I am interested to hear where my proposal fails to improve Leo's functionality while remaining as simple as possible?

[john lunzer]

One last detail, there doesn't need to be a parent collecting node, the most intuitive option is behaving just like copy/cut/paste.

[Edward K. Ream]

On Tue, Apr 5, 2016 at 6:45 AM, john lunzer <lun...@gmail.com> wrote:

​> cffm is clunky in this context,

I'm convinced.​

Leo already has clone-marked-nodes (but it doesn't follow Leo's copy/cut/paste positioning rules). My proposal: create move-marked and copy-marked and make clone-marked-nodes match their behavior. And possibly even rename clone-marked-nodes to simply clone-marked.

Reasonable. Just to be clear, I assume:

1. These commands would move the cloned/moved/copied nodes after c.p, the presently selected node.

2. The command would find all marked nodes, regardless of chapter, and would move the nodes after c.p, regardless of what chapter is in effect.

Edward

[john lunzer]

Yes, placement after c.p. Now that I think about it that is what Copy/Cut/Paste does, places the nodes after c.p, I was failing to find the right terminology to describe that. And the focus should probably be the first of the moved/copied/cloned nodes. Again, this would best match the copy/cut/paste behavior.

Yes on all marked nodes. This is the most flexible and general.

[Chris George]

While we are on the subject: One of my earliest frustrations with Leo was the inability to cut/copy/paste multiple nodes. The intuitive, based on how pretty much every other gui application I have ever used on three different platforms would be to select nodes using ctrl-click to build a selection, then to drag the nodes to the new position with the mouse and release. At this point there is a pop-up asking if you want to copy or move the items, adding an option to clone would make sense for Leo. 

In short, if I select two nodes in the tree pane with the mouse, I can't do anything with them together via the gui. I must act on them one at a time, and there are never any options, the node just gets moved. I understand that with large, complicated outlines the ctrl-click/drag and drop isn't likely to be used often, but as a newbie it was a jarring lesson to learn. I look forward to an easier way than "one at a time", but it would be nice to have this capability available via the mouse as well as using commands.

Chris

[Jacob Peck]

As a newbie a few years back, this was one of my big stumbling blocks.
I feel like the mouse interface doesn't receive much love given that
Edward is rodent-averse (with good reason -- but there are plenty of us
who still use the mouse). IIRC though, so much of Leo's internals rely
on there being only a single selected node that every time someone tries
to add these features they get bogged down and give up.

It is a very jarring experience, but perhaps it's a necessary evil at
the moment?

-->Jake

[john lunzer]

This is why I crafted my methodology the way I did, because it would avoid any such "multi-select" problems.

Many may not know but there is currently one multi-select command. A multi-select delete exists via the right click menu. So there must be some internals to support multi-select actions.

[john lunzer]

On Linux I use a file manager called Ranger (written in pure python! I encourage all to check it out). It has a marking system not unlike Leo's. 

Given powerful mark-based commands it would also be appropriate to have a powerful marking command. Ranger's choice is to use the spacebar to execute a "mark and move to next visible". This makes using marking based commands feel fast and fluid by always moving you forward.

I think Leo would benefit from the same command and ideally the same key-binding. I believe by default the spacebar is not bound to anything when the outline pane is active.

[Edward K. Ream]

On Tue, Apr 5, 2016 at 9:04 AM, john lunzer <lun...@gmail.com> wrote:

Given powerful mark-based commands it would also be appropriate to have a powerful marking command.

​Alt-Ctrl-F (toggle-find-mark-finds-option) toggles the find-command's ​mark-Finds checkbox.

Ranger's choice is to use the spacebar to execute a "mark and move to next visible". This makes using marking based commands feel fast and fluid by always moving you forward.

I think Leo would benefit from the same command and ideally the same key-binding.

​ ​

I believe by default the spacebar is not bound to anything when the outline pane is active.

​Please file an enhancement request.

Edward