Yesterday Félix and I cleared up several issues in a zoom meeting. We now are in agreement on all major issues.
The project is going very well. Félix is responsible for the ts side, I am helping with the python side, leobridgeserver.py. I'll be using PR's to suggest all changes. No more cowboy commits ;-) Yesterday's zoom focused on two topics, command handling and syntax coloring... *Command handling* Note: Let "br" denote the LeoBridgeIntegController class, in leobridgeserver.py. *br.leoCommand* can now execute *any* Leo command, given only the command's name. The code contains no special cases. However, any Leo command can be "overridden" by providing a br.x method, where x is the name of the method that implements the command. x can be a Commander method, a method of one of Leo's subcommanders, or a method defined by @command or @button. This scheme is a bit *too* general. It allows the ts side to execute gui-specific code, and other inappropriate commands. The solution will be straightforward. The ts side calls* br.getCommands *to get a list of all of Leo's commands. Rather than returning *all* methods in c.commandsDict, br.getCommands will filter out any inappropriate commands. For now, I'll create a hand-crafted *list of suppressed commands*. This list will likely suffice indefinitely. *Important*: br.getCommands must start with the methods in c.commandsDict. It's not possible to create a *fixed *list of all commands because c.commandsDict will include commands defined by @command or @button. In other words, there is no such thing as a list of "all" of Leo's commands. This list always depends on each .leo file. Otoh, creating a *fixed* list of suppressed commands *will* work. Its much easier to suppress commands than to include missing commands :-) Clear? Another complication. At present, expanding outline abbreviations involves gui-related interaction to handle ",," expansions. It will be necessary (somehow) to handle this interaction in the br class. More generally, some way may be needed to handle leo's c.interactive* commands. I am confident that this will be possible. *Syntax coloring* Ideally, we would like to delegate syntax coloring for all languages to vs code's existing syntax colorers. Alas, this is appears to be impossible. I'll omit the details. The workaround will be to create a new syntax colorer, one for each language. Let's call them leo-javascript, leo-python, etc. One or two .json files define each existing vs code syntax colorer. They can be surprisingly complex. Rather than hand-crafting these new .json files, I have volunteered to write a script to merge coloring for Leo's syntax (section references and directives) into the existing .json files. The idea is straightforward; this will likely become a major project. No matter, leoInteg must have the best possible syntax coloring. *Summary* Work is going well. Félix is responsible for the dev branch. I am helping with the python code in the ekr branch. leoInteg can execute *any* Leo command via the Command Palette! Some commands are not relevant and should not be shown. leoInteg already can execute Leo's killer git-diff command with *no* special case code. This shows that leoInteg's architecture is sound and flexible. Significant work will be needed to handle Leo's other killer commands: clone-find and tree-oriented abbreviations. Imo, leoInteg's architecture will be up to the challenge. Syntax coloring is a major project. I shall create a script to merge json descriptions of all standard vs code languages with the json describing Leonine syntax. 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/edc766f6-07a5-4f60-bc10-f96cc2d46ac2o%40googlegroups.com.
