Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Please discuss: branch 'felix-fix-script-results'

49 views
Skip to first unread message

Félix

unread,
Apr 19, 2025, 8:40:39 PMApr 19
to leo-editor
Hi everyone!  

I've made two small but useful improvements which you can preview in the branch 'felix-fix-script-results'.

1- Return values from commands

Until now, calling a command with doCommandByName, executeMinibufferCommand or doCommand didn’t return the result of the underlying method. (c.keyHandler.funcReturn was removed a while ago) That’s now fixed — these functions will return whatever the command’s method returns.

For example, the convert-blanks command (which replaces leading spaces with tabs) returns True if it made any changes, and False otherwise. Previously, calling it with c.doCommandByName('convert-blanks') would return None, but now it correctly returns the boolean result — just like calling c.convertBlanks() directly.

2 - Another feature for user-defined scripts

I've also added a way for user-defined scripts (those inside @command or @button nodes) to return values as well. Since top-level return statements aren't allowed in scripts executed with exec, you can now define a global variable named result, and Leo will return its value after the script runs. For example:

global result
result = 42

This makes it easier to write scripts that communicate results back to automation tools, plugins, or other parts of an experimental workflow.

I've attached a small Leo file demonstrating a use case for this.

I'm just curious to know if these two changes are okay with y’all—especially the second one. 😬

Félix
demo-doCommandByName.leo

Edward K. Ream

unread,
Apr 20, 2025, 8:15:51 AMApr 20
to leo-editor
On Saturday, April 19, 2025 at 7:40:39 PM UTC-5 Félix wrote:

I've made two small but useful improvements which you can preview in the branch 'felix-fix-script-results'.

Thanks for this work. My short response: the PR is useful and sound. More details below.
 
1- Return values from commands

Until now, calling a command with doCommandByName, executeMinibufferCommand or doCommand didn’t return the result of the underlying method. (c.keyHandler.funcReturn was removed a while ago) That’s now fixed — these functions will return whatever the command’s method returns.

For example, the convert-blanks command (which replaces leading spaces with tabs) returns True if it made any changes, and False otherwise. Previously, calling it with c.doCommandByName('convert-blanks') would return None, but now it correctly returns the boolean result — just like calling c.convertBlanks() directly.

This feature eliminates a confusing difference between various parts of Leo's API. I fully approve this change.

The diffs for c.executeScriptHelper do not reveal a subtle detail. Happily, this detail will cause no problem.

The detail: c.executeScript and c.executeScriptHelper take a namespace kwarg. What happens if namespace (a dict) contains a "result" key? Happily, the answer is, nothing. The local d var (another dict) does not contain a "result" key, so the lines:

if namespace:
    d.update(namespace)

will not affect the namespace kwarg.  Therefore, the PR will not affect the exec statement in any way.

Note: I do not believe this analysis needs to be part of the new documentation ;-) You might mention it in the PR itself.

2 - Another feature for user-defined scripts

I've also added a way for user-defined scripts (those inside @command or @button nodes) to return values as well. Since top-level return statements aren't allowed in scripts executed with exec, you can now define a global variable named result, and Leo will return its value after the script runs. For example:

global result
result = 42

The analysis above shows that "polluting" the namespace of the exec statement will never cause any problem.

I've attached a small Leo file demonstrating a use case for this.

This demo works as advertised in the felix-fix-script-results branch. The whole-process button will loop indefinitely in devel, but that's not a real problem ;-)

Let's merge this PR soon.

Edward

jkn

unread,
Apr 20, 2025, 3:55:56 PMApr 20
to leo-editor
I like the sound of this! I will take a look, thanks for your work here, Felix.

    J^n

Félix

unread,
Apr 20, 2025, 9:57:55 PMApr 20
to leo-editor
Thanks for the comments! 

>  This demo works as advertised in the felix-fix-script-results branch. The whole-process button will loop indefinitely in devel,  ....
oh yeah,  haha! -> Try with the  felix-fix-script-results branch, otherwise the whole-process button will loop !


>  Let's merge this PR soon.
I agree. 

Félix

Edward K. Ream

unread,
Apr 20, 2025, 10:27:16 PMApr 20
to leo-e...@googlegroups.com


On Sun, Apr 20, 2025 at 8:57 PM Félix <felix...@gmail.com> wrote:
Thanks for the comments! 

You're welcome. Please merge this PR when you are ready.

Edward

Félix

unread,
Apr 21, 2025, 2:55:23 PMApr 21
to leo-editor
Thanks for merging it for me! :)

I'll release an updated LeoJS version that mirrors all the updates and improvements since 6.8.3 very soon, (in a few days) as the rest of the issues for 6.8.4 have no equivalent in LeoJS. (unless something big pops up!) 

Félix

Edward K. Ream

unread,
Apr 21, 2025, 5:02:11 PMApr 21
to leo-e...@googlegroups.com
On Mon, Apr 21, 2025 at 1:55 PM Félix <felix...@gmail.com> wrote:
Thanks for merging it for me! :)

I'll release an updated LeoJS version that mirrors all the updates and improvements since 6.8.3 very soon, (in a few days) as the rest of the issues for 6.8.4 have no equivalent in LeoJS. (unless something big pops up!) 

I know of no open issue that affects LeoJS. I'd like to fix #4325 before releasing Leo 6.8.4, but that shouldn't affect LeoJS.

Edward
Reply all
Reply to author
Forward
0 new messages