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. On Sunday, October 10, 2021 at 10:30:05 AM UTC-4 Edward K. Ream wrote: > 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 > > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/1058697b-3a88-4553-8c41-3c78968404b3n%40googlegroups.com.
