weirdness in key bindings when loading new/old outlines

[jkn]

Hi All (and welcome back, Edward!).

I have muttered about this before but now think I have a concrete example to show. The behaviour of defined commands seems to change according to outline being edited...

Here are some step to reproduce.

1) my myleosettings.leo has some @command nodes, and some @shortcut nodes to define the keystrokes for these commands.

1a) you can sort-of see the effects of these by entering 'show-bindings' in the minibuffer. An extract of the output of this (when a normal outline, with no shortcut or commands, is being edited) is:

Plain keys...
M    body: End           crisp_end
M    tree: End           end-of-line
M    body: Home          crisp_home
M    tree: Home          back-to-home
M    body: Insert        paste-text
M    tree: Insert        insert-node
F     all: Keypad++      crispKeypadPlus
F     all: Keypad+-      crispKeypadMinus

1c) The 'F' denotation seems a bit odd here; it is supposed to mean 'defined in the loaded .leo file'. In fact, this is not true, all of these are defined in myleosettings.leo

1d) The difference seems to be that the two 'F' commands are defined like

    @command crispKeypadPlus @key=Keypad+plus

        ...

    @command crispKeypadMinus @key=Keypad+minus

        ...

however this is a minor bug I think (although it confused me a bit)

2) if, however, I then create a new outline, the bindings in myleosettings.leo do not seem to be correctly applied. I would expect all of the above to be in place; however 'show-bindings' when editing the new outline gives (again, extracted)

M    tree: End           end-of-line
M    tree: Home          back-to-home
M    body: Insert        paste-text
M    tree: Insert        insert-node
D     all: Keypad++      crispKeypadPlus
D     all: Keypad+-      crispKeypadMinus

That is:

   - the bindings previous mis-denoted as 'F' are now mis-denoted as 'D' !

   - I have lost the bindings:

       M    body: End           crisp_end
       M    tree: End           end-of-line

3) I have just now loaded an existing outline (ie. as well as the other outlines_, and now both this outline, and the 'new' outline, which was previously misbehaving, show the original correct bindings (albeit with the 'F' not 'M' buglet):

M    body: End           crisp_end
M    tree: End           end-of-line
M    body: Home          crisp_home
M    tree: Home          back-to-home
M    body: Insert        paste-text
M    tree: Insert        insert-node
F     all: Keypad++      crispKeypadPlus
F     all: Keypad+-      crispKeypadMinus

I'm not misunderstanding things here, am I? With no @settings in an outline, or when creating a new outline, the bindings in myleosettings.leo should be the same across outlines?

Puzzling...

    J^n

[jkn]

correction to part of what I wrote:

   - I have lost the bindings:

       M    body: End           crisp_end

       M    body: Home          crisp_home

[Edward K. Ream]

On Thu, Apr 3, 2025 at 2:28 PM jkn <jkn...@nicorp.f9.co.uk> wrote:

Hi All (and welcome back, Edward!).

:-)

I have muttered about this before but now think I have a concrete example to show. The behaviour of defined commands seems to change according to outline being edited...

Thanks for this report. I'll look into it after I merge the big PR.

Edward

[jkn]

Hi Edward

    just a very light nudge on this, as I hit it again today when creating a new outline (which I do rarely).

- setup: I have some @command shortcuts in myLeoSettings.leo

- create a new outline

- try to use the shortcuts - without success

- exit and restart Leo, with the new outline present

- now the shortcuts work when in the new outline

The previous posts above give some more gory details...

    Regards, J^n

[Edward K. Ream]

On Tue, June 17, 2025 at 7:58 AM jkn wrote:

>  just a very light nudge on this, as I hit it again today when creating a new outline (which I do rarely).

I have just created #4371 for this issue.

I have spent considerable time summarizing the original report as concisely as I can. Please proofread the first comment of the issue and report any misunderstandings I may have.

Also note that your original post implies that key bindings for the crispKeypadPlus and crispKeypadHome commands are also set via @shortcuts nodes. Is this correct??

Edward

[Edward K. Ream]

On Thursday, April 3, 2025 at 2:28:25 PM UTC-5 jkn wrote:

I have muttered about this before but now think I have a concrete example to show. The behaviour of defined commands seems to change according to outline being edited...

I have just closed #4371 because the primary complaint is invalid. But your confusion is understandable. By default, `@button` and `@command` nodes are local  to myLeoSettings.leo.  You define common `@button` nodes as follows:

@settings
  @buttons
    @button test @key=f3

My apologies for not setting you straight earlier.

Edward

[Edward K. Ream]

On Tuesday, June 24, 2025 at 11:52:29 AM UTC-5 Edward K. Ream wrote:

I have just closed #4371 because the primary complaint is invalid. But your confusion is understandable. By default, `@button` and `@command` nodes are local  to myLeoSettings.leo.  You define common `@button` nodes as follows:

@settings
  @buttons
    @button test @key=f3

My apologies for not setting you straight earlier.

I have just opened #4377 to fix incorrect legends in the show-bindings command.

Edward

[jkn]

Hmm. My @command nodes are within an @commands node in myLeoSettings.leo (at least in the machine I am on right now).

I will try to make a super-simple example to double-check what I have been seeing.

Thanks for your attention to this.

    J^n

[jkn]

OK, I have made some further investigation using a minimal, almost-empty myLeoSettings.leo.

I think the issue I am seeing is more about the use of @shortcuts than @commands

1) I have a myLeoSettings.leo like this:

@settings

    @commands

        @command test_cmd1 @key=Alt+Ctrl+1    # holds "g.es("test_cmd1")"

        @command test_cmd2 @key=Alt+Ctrl+2    # holds "g.es("test_cmd2")"

If I start Leo with this in force, then with a new outline, the key shortcuts give the expected output.

2) if instead I have a myLeoSettings.leo like this:

@settings

    @commands

        @command test_cmd1    # holds "g.es("test_cmd1")"

        @command test_cmd2    # holds "g.es("test_cmd2")"

    @keys

        @shortcuts  # body is:" test_cmd1 = Ctrl+Alt+1 \n test_cmd2 = Ctrl+Alt+2", on two lines

(which I would expect to have the same effect)

Then I see the issue - Ctrl+Alt+1 and Ctrl+Alt+2 work in 'original' files, but appear not to be in effect if a new .leo file is created

Does that help? Or is there something similar to the '@commands ... @command' arrangement that is needed for @shortcuts node settings to be 'global'?

My original (somewhat garbled) report does mention using both arrangements. I am not clear why I have both, it was probably just my experiments. But generally, I guess I would expect @shortcuts settings to be global?

    Thanks a lot

    J^n

[jkn]

PS: I'm on a different machine without Leo ATM, but I think I am right in saying that in case (2),

and in the new outline, I can use the minibuffer to execute 'test_cmd1' and 'test_cmd2', even though the shortcuts don't appear to be in effect.

[Edward K. Ream]

On Wed, Jun 25, 2025 at 7:57 AM jkn <jkn...@nicorp.co.uk> wrote:

PS: I'm on a different machine without Leo ATM, but I think I am right in saying that in case (2),

and in the new outline, I can use the minibuffer to execute 'test_cmd1' and 'test_cmd2', even though the shortcuts don't appear to be in effect.

Everything works as expected on my machine.

Edward

[jkn]

Well, I've just replicated the unexpected (to me) behaviour on a different machine. Both are Linux machines, this one is:

"""

Leo Log Window
Leo 6.8.5-devel, main branch, build d5f0d03178
2025-05-16 08:51:35 -0500
Python 3.9.5, PyQt version 6.7.3
linux

"""

I've attached the minimal ~/.leo/myLeoSettings.leo I am using.

Steps to reproduce:

- invoke Leo

- observe that Ctrl-Alt-1 and Ctrl-Alt-2 print something in the log window, as expected, and via the @shortcuts to @command test_cmd1 and @command test_cmd2

- create a new Leo outline via File | New

- observe that these keystrokes do not print anything in the log window when in this outline

- observe that Alt-X and then test_cmd1 *does* print into the log window from this new outline

    J^n

[Edward K. Ream]

On Wed, Jun 25, 2025 at 10:51 AM jkn <jkn...@nicorp.co.uk> wrote:

> Well, I've just replicated the unexpected (to me) behaviour on a different machine.

...

> I've attached the minimal ~/.leo/myLeoSettings.leo I am using.  

Thanks. I'll have another look.

Edward

[Edward K. Ream]

At last! With your version of myLeoSettings.leo I do see the behaviour you describe.

I have reopened #4371.

Edward

[jkn]

Thank you. Apologies if it has taken me a while to provide the necessary information.

    J^n

[Edward K. Ream]

On Thu, Jun 26, 2025 at 5:35 AM jkn wrote:

Thank you. Apologies if it has taken me a while to provide the necessary information.

NP. It's all good.

The problem arises because your myLeoSettings.leo uses an @shortcuts node to bind keys to your `@command` scripts. Fixing this buglet may not be straightforward. We shall see.

The workaround (and imo best practice) would to create the bindings in the `@command` scripts:

@command test_cmd1 @key=Ctrl+Alt+1

@command test_cmd2 @key=Ctrl+Alt+2

Edward

[jkn]

Yes, I have very nearly done this a couple of times ... as I say above, I am not 100% sure why I have some one way, and some the other. This report was originally to try and understand what was going on, and why. FWIW I would have thought that the separated use of @shortcuts was more 'best practice', but there you go...

BTW, I can confirm the behaviour of (merged) https://github.com/leo-editor/leo-editor/pull/4378 seems to correct issue https://github.com/leo-editor/leo-editor/pull/4378. Sorry I didn't get chance to review the PR, and thanks to Thomas for doing so.

    Thanks

    J^n

 

[jkn]

PS: Just realised/remembered - one reason for preferring the @shortcuts node method is that only it AFAIK allows the use of 'body', 'tree' etc. modifiers...

command_name ! body = KeyStroke

command_name ! tree = AnotherKeyStroke

[Edward K. Ream]

On Thursday, June 26, 2025 at 5:50:13 AM UTC-5 Edward K. Ream wrote:

Fixing this buglet may not be straightforward.

A one-line fix seems to suffice.  PR #4372 is ready for review.

Edward

[Edward K. Ream]

On Thu, Jun 26, 2025 at 6:16 AM jkn <jkn...@nicorp.co.uk> wrote:

PS: Just realised/remembered - one reason for preferring the @shortcuts node method is that only it AFAIK allows the use of 'body', 'tree' etc. modifiers...

Maybe :-) There are special cases everywhere in the key handling code.

Edward