Hoist an @chapter node leaves a non-visible node selected

[SegundoBob]

Hoists are enabled by enabling plugin chapter_hoist.py. Hoist is done by clicking button "save-hoist" which does the hoist and creates a button to that when clicked will redo the hoist.

Why is an @chapter node treated differently by hoist? I don't know.

If you start in this should-never-happen-condition with a non-visible node selected, then even good positioning commands (like Alt-Up) go wrong. So you need to be careful when testing positioning commands that you start with a valid position.

[SegundoBob (bhossley)]

Test System:
Ubuntu Studio 11.04
Leo-editor revision 4591

Leo-editor log pane on startup:

Leo Log Window
Leo 4.9 final, build 4411, June 21, 2011
Python 2.7.1, qt version 4.7.2
linux2
setting leoID from os.getenv('USER'): 'bob'
load dir: /home/bob/bzrWork/pluginPath/leo/core
global config dir: /home/bob/bzrWork/pluginPath/leo/config
home dir: /home/bob
reading settings in /home/bob/bzrWork/pluginPath/leo/config/leoSettings.leo
reading settings in /home/bob/.leo/myLeoSettings.leo
reading settings in /home/bob/tmp/c.leo
reading: /home/bob/tmp/c.leo
global @command command-reverse-siblings
global @command command-goto-last-child alt-=

[Edward K. Ream (edreamleo)]

On Sat, Oct 15, 2011 at 10:37 PM, SegundoBob <email address hidden> wrote:

>  Why is an @chapter node treated differently by hoist?  I don't know.

@chapter could be considered a form of hoist. The code is very complex.

See my remarks re bug 875327.

Edward

[Edward K. Ream (edreamleo)]

Fixed in the trunk at rev 5092. All usual tests pass.

As a bonus, selecting any chapter explicitly now clears all hoists.
This is, I believe, the most intuitive form of operation.
It could be changed easily, if desired, but I doubt anyone would notice.

[Edward K. Ream (edreamleo)]

> As a bonus, selecting any chapter explicitly now clears all hoists.

Oops. I had forgotten that c.hoistStack is involved in the chapters machinery. I'll remove this "bonus" immediately.

[Edward K. Ream (edreamleo)]

> Oops. I had forgotten that c.hoistStack is involved in the chapters machinery. I'll remove this "bonus" immediately.

Done at rev 5093, which also fixes bug 831658: @url doesn't leave Chapter.

[SegundoBob (bhossley)]

The problem was not fixed.

Test Procedure:
Plugin chapter_hoist must be enabled.
Open hoist-at-chapter-test.leo (attached)
Select the name with headline "@chapter C1".
Left-click the save-hoist button.
Now the bug has occurred. Note that the body displayed is "C1-Body". This is the body of the node with headline "@chapter C1" which is not displayed in the outline pane and is not currently selected.
* See below
Type something into the displayed body, making it for example "C1-Body-new".
Now left-click the dehoist button. Note that you really did change the body of the "@chapter C1" while this node was not shown in the outline pane.

* Left-clicking the currently selected node (which has headline "L1-H1") has no effect, but left-clicking the node with headline "L2-H1" does bring the body pane back into synch with the node selected in the outline pane.

Test System:
Ubuntu 11.10 with Fluxbox window manager
Leo Log Window
Leo 4.9.1 devel, build 5106, 2012-03-09 19:20:49
Python 2.7.2, qt version 4.7.3
linux2
setting leoID from os.getenv('USER'): 'bob'
load dir: /home/bob/bzr/LeoLatest/leo/core
global config dir: /home/bob/bzr/LeoLatest/leo/config
home dir: /home/bob
reading settings in /home/bob/bzr/LeoLatest/leo/config/leoSettings.leo
reading settings in /home/bob/.leo/myLeoSettings.leo

[SegundoBob (bhossley)]

On reflection, I realize that the bug was probably half fixed. I believe before the half-fix, there was no selected node showing in the outline pane at the point marked by an asterisk in the test procedure above. So the half-fix makes the node with headline "L1-H1" show as selected in the outline pane. Unfortunately, this makes the bug worse, because now the body shown does not belong to the clearly selected node. Whereas before when no node was shown as selected, the user should have wondered, which node body is being shown?

[Edward K. Ream (edreamleo)]

On Sat, Mar 10, 2012 at 12:03 AM, SegundoBob <email address hidden> wrote:
> On reflection, I realize that the bug was probably half fixed.  I
> believe before the half-fix,   there was no selected node showing in the
> outline pane at the point marked by an asterisk in the test procedure
> above.  So the half-fix makes the node with headline "L1-H1" show as
> selected in the outline pane.  Unfortunately, this makes the bug worse,
> because now the body shown does not belong to the clearly selected node.
> Whereas before when no node was shown as selected, the user should have wondered, which node body is being shown?

Many thanks for your diligence in testing. I'll fix this immediately.

Edward

[Edward K. Ream (edreamleo)]

On Sat, Mar 10, 2012 at 9:01 AM, Edward K. Ream <email address hidden> wrote:
> On Sat, Mar 10, 2012 at 12:03 AM, SegundoBob <email address hidden> wrote:

So the half-fix makes the node with headline "L1-H1" show as
>> selected in the outline pane.  Unfortunately, this makes the bug worse,
>> because now the body shown does not belong to the clearly selected node.

Fixed (cleanly) at rev 5107 of the trunk. All unit tests pass,
including a new unit test.

Edward

[SegundoBob (bhossley)]

The fix works for me.

Ubuntu 11.10 with Fluxbox
Leo Log Window
Leo 4.9.1 devel, build 5113, 2012-03-10 15:43:07
Python 2.7.2, qt version 4.7.3
linux2
setting leoID from os.getenv('USER'): 'bob'
load dir: /home/bob/bzr/LeoLatest/leo/core
global config dir: /home/bob/bzr/LeoLatest/leo/config
home dir: /home/bob
reading settings in /home/bob/bzr/LeoLatest/leo/config/leoSettings.leo
reading settings in /home/bob/.leo/myLeoSettings.leo
reading settings in /media/datw1/BobH/1/Leo/Leo.leo

[Edward K. Ream (edreamleo)]

On Sat, Mar 10, 2012 at 5:55 PM, SegundoBob <email address hidden> wrote:
> The fix works for me.

Thanks for the confirmation. It was important to fix this bug.

EKR