Bug: expand-next-level keeps counting beyond maximum level

[john lunzer]

I've just discovered the awesomeness of combining hoisting and expand-next-level/expand-prev-level to quickly navigate and focus on specific content.

I've also discovered that if you continue executing expand-next-level N number of times after the maximum number of levels have been expanded you have to execute expand-prev-level N number of times for it to start contracting.

[Edward K. Ream]

On Wed, Apr 27, 2016 at 7:21 AM, john lunzer <lun...@gmail.com> wrote:

I've just discovered the awesomeness of combining hoisting and expand-next-level/expand-prev-level to quickly navigate and focus on specific content.

I've also discovered that if you continue executing expand-next-level N number of times after the maximum number of levels have been expanded you have to execute expand-prev-level N number of times for it to start contracting.

​Good catch. I'm working on it now.

EKR

[Edward K. Ream]

​Try rev 41d70ab. It always announces the actual expansion level, not the requested level.

EKR

[john lunzer]

Yep, works as expected now. 

[Edward K. Ream]

On Wed, Apr 27, 2016 at 3:16 PM, john lunzer <lun...@gmail.com> wrote:

Yep, works as expected now. 

​Good to know.  What do you think about reporting the level in the log pane?  Might it be better to report it in the status area?

Edward

[john lunzer]

I do think it would be better in the status area. It's a little distracting in the log pane.

[Edward K. Ream]

On Wed, Apr 27, 2016 at 3:31 PM, john lunzer <lun...@gmail.com> wrote:

I do think it would be better in the status area. It's a little distracting in the log pane.

​Done at ​8fec891.

EKR

[john lunzer]

There is a small bug with expand-prev-level and chapters. You must have a chapter with a one child node at the next level and then any number of child nodes at the levels after that. 

Here is an example:

@chapter parent

childLevel1

childLevel2

Execute chapter-select-parent, then fully expand, then put the focus on childLevel2 then press UpArrow so the focus is on childLevel1, now execute expand-prev-level. The tree will not contract, but Level 1 will show in the status area. If I try to use the DownArrow to focus to childLevel2 I cannot, but I can use the RightArrow to focus to childLevel2.

[Edward K. Ream]

On Thu, Apr 28, 2016 at 6:59 AM, john lunzer <lun...@gmail.com> wrote:

There is a small bug with expand-prev-level and chapters. You must have a chapter with a one child node at the next level and then any number of child nodes at the levels after that. 

Here is an example:

@chapter parent

childLevel1

childLevel2

Execute chapter-select-parent, then fully expand, then put the focus on childLevel2 then press UpArrow so the focus is on childLevel1, now execute expand-prev-level. The tree will not contract, but Level 1 will show in the status area. If I try to use the DownArrow to focus to childLevel2 I cannot, but I can use the RightArrow to focus to childLevel2.

​This is, in fact, the expected behavior.  The expand-next/prev-level commands are local to (rooted by) the selected headline.  The "root" of the expansion, in your example, is childLevel2, so nothing more can be expanded.

Perhaps this is not intuitive, but this behavior has nothing to do with chapters, as you can verify yourself.  I'll entertain an enhancement/change request, but this is the intended behavior and I think the Alt-keys are good enough.  What do you think?

Edward

[john lunzer]

You're right, it's not chapter related. But there is still a bug.You can use the previous example, even add further levels of children for greater effect. Make tree fully expanded, select childLevel1 by whatever means. Then use the UpArrow to select the @chapter parent parent node. Now execute expand-prev-level. You will notice that nothing gets contracted. 

Additionally the LeftArrow and DownArrow do nothing work. LeftArrow should contract, the @chapter parent node but does now and the DownArrow should navigate down a node but does not.

If you press RightArrow you'll see that the tree gets contracted when the next node is selected.

What appears to be happening is that the outline is not getting updated after expand-prev-level but also it's locking some keys in the process.

[Edward K. Ream]

On Thu, Apr 28, 2016 at 10:15 AM, john lunzer <lun...@gmail.com> wrote:

You're right, it's not chapter related. But there is still a bug.

​Let's have this conversation after b1 goes out the door.  If this is a bug, is small, and I don't see any problem with it.  It's time to turn to release-related matters.

EKR

[john lunzer]

No problem. This is a lower priority.

[john lunzer]

I'm just posting again for documentation sake. This bug is small because I'm sure very few people use expand-next-level and expand-prev-level, if anyone did they would have noticed the original bug that started this thread.

The bug itself breaks Leo's outline functionality temporarily. Upon further testing I can create a situation where after executing expand-prev-level I cannot access a subtree without entering it with the right arrow or using the mouse. Using the down arrow will skip over the whole subtree as if it didn't exist if there is a sibling at that level below it. Subsequently using the up arrow will skip over the subtree again. I do not believe this to be the intended behavior.

If you wish I can submit an issue detailing this thread. I presume no timetable, as I said this is a pretty low priority.