ENB: 'good' and 'bad' lists in leoserver.py

[Edward K. Ream]

The LeoServer class in leoserver.py defines lists of "good" and "bad" Leo commands. This Engineering Notebook post discusses speculative ideas for reducing, eliminating, or rethinking these lists.

tl;dr:  Little or nothing more needs to be done! But see the summary.

The bad list

The comment associated with the  "bad" list is: "command names that connected clients should ignore."  This list appears essential. Some commands don't make sense inside vs-code.

For example, the debugger commands (db-*) imply that calls to pdb.set_trace exist inside Leo. Hmm. Maybe it's time to retire Leo's 'debug' and  'db-*' commands. I'll look into this.

vs-code will supersede some Leo commands, such as:

- Leo's autocompletion and calltips commands.

- Leo's shell commands.

- Commands related to clicks in Leo's (qt) window.

- Commands related to Leo's free_layout plugin.

- Commands related to other (Leo) plugins.

etc.!

In short, most items in the "bad" list should remain.

The good list

The comment associated with the "good" list is: "Defined commands that should be available in a connected client."

Leo has various dictionaries that describe available commands.  Naively, I would suppose that all of Leo's commands might be part of the "good" list, except for:

1. Commands in the "bad" list, and

2. Commands that require user interaction from Leo's gui.

Yes, we could add all interactive commands to the bad list, but we might not need to do this.  For example, many (all?) of Leo's interactive find commands call find.start_state_machine. Suppose this method raises, say, g.InteractionError if g.in_leo_server is True. The LeoServer class would catch InteractionError and add the attempted command to the bad list.

Another idea: A decorator, say @override, could mark all LeoServer methods that override Leo commands.  The effect of this decorator might be to add items to the "good" list. But this may not be necessary!

Summary

The "bad" list probably must remain, possibly with a few tweaks. It may be time to retire Leo's 'debug' and 'db-*' commands.

Perhaps a script could help create the "good" list.

I throw these ideas out for comment and discussion. There is no urgent need to change leoserver.py. Félix, please comment.

Edward

[tbp1...@gmail.com]

This raises an interesting question - suppose you open an outline, and the outline adds a new command via its @settings tree.  How should leointeg learn about the new command?

The idea of a decorator appeals to me somewhat, except for the matter of applying it to the existing code base.  For new commands, I think a decorator to announce that the command is safe for leoserver to pass along would make sense.  Say, @leoserver or @interactive. That would require the command author to understand how to know what the rules are for this.

I don't understand the part about leoserver modifying commands well enough to form an opinion there.

[Edward K. Ream]

On Sun, Oct 10, 2021 at 11:36 AM tbp1...@gmail.com <tbp1...@gmail.com> wrote:

This raises an interesting question - suppose you open an outline, and the outline adds a new command via its @settings tree.  How should leointeg learn about the new command?

Yes, that's a problem.  Not sure what leoInteg does.

The idea of a decorator appeals to me somewhat, except for the matter of applying it to the existing code base. 

I was suggesting a new decorator to be used only in leoserver.py. As I said, it may not be necessary even in this limited context.

Edward