why does goto-prev/next-visible command change focus to body?

[jkn]

(I seem to be on a mild Leo roll at the moment...)

The Up/Down arrow keys, when focus is in the tree, seem by default to be bound to

goto-prev-visible

and

goto-next-visible

for navigating nodes. There are also similar commands

goto-prev-node

and

goto-next-node

There seem to be two differences between these sets of commands:

1) goto-X-visible navigates the tree "as seen". Whereas goto-X-node expands nodes as the tree is traversed.

Thus for most of the time. goto-X-visible makes most sense, I would think. However:

2) goto-X-visible changes the focus to the body after running!

This means that I can't press the Up key multiple times to move around in the tree, and causes me to have to use the mouse.

Is this intentional? It seems a bit weird. I would like a (core) command that allowed me to navigate the visible nodes of a tree using the Up and Down keys repeatedly. It doesn't seem unreasonable...

I had a look at the code for the different commands. There is a reference to

    c.endEditing    # 2011/05/28: A special case.

But it is not clear to me that this is the cause of the difference.

I am a bit surprised that I have not seen this mentioned before - does everyone use the mouse, r something?

Thanks, J^n

[Thomas Passin]

Your change of focus isn't happening for me.  Neither using the arrow keys nor running goto-next-visible changed the focus to the body.  Looking at the code for the method c.endEditing.  c.endEditing() calls qtree.endEditLabel(), and  that kicks out the headline editor but without changing focus away from the tree:

def endEditLabel(self) -> None:
    """
    Override LeoTree.endEditLabel.

    Just end editing of the presently-selected QLineEdit!
    This will trigger the editingFinished_callback defined in createEditorForItem.
    """
    item = self.getCurrentItem()
    if not item:
        return
    e = self.getTreeEditorForItem(item)
    if not e:
        return
    # Trigger the end-editing event.
    w = self.treeWidget
    w.closeEditor(e, EndEditHint.NoHint)
    w.setCurrentItem(item)

So now someone has to figure out why you got different results from me. I know nothing about the tree and its programming.

[Félix]

Like Thomas, for me, using the up down keys (or any  arrow home/end pgup pgdn keys) with focus in the tree to navigate has always kept my focus in the tree. 

You may have a setting set to put focus in body upon navigation set up to True. (cant remember on top of my head which setting does that & I'm on my phone right now)

Félix

[Edward K. Ream]

On Thu, Nov 7, 2024 at 4:24 PM jkn <jkn...@nicorp.f9.co.uk> wrote:

(I seem to be on a mild Leo roll at the moment...)

So your next step as a power user is to read the code to answer your question :-) You too, Thomas.

Search for 'goto-next-visible' in leoPy.leo (your personal copy of LeoPyRef.leo) or LeoPyRef.leo itself.

Leo uses decorators to define each command. By convention, all command names start with a single quote.

You will find:

@g.commander_command('goto-next-visible')
def selectVisNext(self: Cmdr, event: LeoKeyEvent = None) -> None:
    """Select the visible node following the presently selected node."""
    c, p = self, self.p
    if not p:
        return
    if c.canSelectVisNext():
        p.moveToVisNext(c)
        c.treeSelectHelper(p)
    else:
        c.endEditing()  # 2011/05/28: A special case.

The special case only happens if the move doesn't happen, so let's assume, as the name implies, that c.treeSelectHelper sets the focus.

Note: any Leo dev should know that p.moveToVisNext has no effect on Leo's gui. Only 'c' (Commander) methods do that.

So your attention should immediately shift to c.treeSelectHelper. Search for def treeSelectHelper:

def treeSelectHelper(self, p: Position) -> None:
    c = self
    if not p:
        p = c.p
    if p:
        # Do not call expandAllAncestors here.
        c.selectPosition(p)
        c.redraw_after_select(p)
    c.treeFocusHelper()  # This is essential.

The last line executed is c.treeFocusHelper:

def treeFocusHelper(self) -> None:
    c = self
    if c.stayInTreeAfterSelect:
        c.treeWantsFocus()
    else:
        c.bodyWantsFocus()

So the ivar  c.stayInTreeAfterSelect determines the focus.

Within Leo, c is an instance of the Commands class. Search for class Commands. You'll see lots of ivars.

Within the class node, search for stayInTreeAfterSelect. First you'll find:

self.stayInTreeAfterSelect = False

Keep searching!  In c.initConfigSettings you'll find:

c.stayInTreeAfterSelect = getBool('stayInTreeAfterSelect')

So there should be a setting, @bool stayInTreeAfterSelect

Use Leo's 'leo-settings' command (Alt-X leo-set<tab>) to open LeoSettings.leo.

Search for  @bool stayInTreeAfterSelect

You'll find the default is True. The body text contains:

True: (Recommended) Selecting an outline node leaves the focus in the outline pane.
If this is False it will be harder to use the arrow keys in the headline.
False: (Legacy) Selecting an outline node transfers focus to the body pane.

How hard was that?

Edward

[jkn]

Hi Edward

    Thanks very much - you have beaten me to the steps I was going to take following Thomas' reply.

I only have small time windows to investigate and experiment with Leo, my first post was to check whether others have the same experience.

I came on this morning (UK time) to say "Thanks Thomas, I am guessing that there will a setting governing this behaviour, I will follow up".

PS: your comment about only c.X methods affecting the gui makes sense, but I had not fully appreciated it, thanks

    Regards

    Jon N

[jkn]

PS: (another breadcrumb on the path, as it were)

The implication (I will follow up ;-) of this is that @bool stayInTreeAfterSelect works 'differently' for goto-prev/next-node, and goto-prev/next-visible, since these exhibit different "stay in tree focus" behaviour for me, and both use treeSelectHelper(). That still seems odd...

    J^n

[Edward K. Ream]

On Fri, Nov 8, 2024 at 2:01 AM jkn <jkn...@nicorp.f9.co.uk> wrote:

Hi Edward

    Thanks very much - you have beaten me to the steps I was going to take following Thomas' reply.

You're welcome!

PS: your comment about only c.X methods affecting the gui makes sense, but I had not fully appreciated it, thanks

I'm glad that comment was helpful.

Edward