All right ladies and gents, We've got some ALT+X 'minibuffer' action going on, on the 'dev' branch: try typing alt+x and then 'hoi' for example....
:D -- Félix On Tuesday, July 21, 2020 at 10:12:32 AM UTC-4, Edward K. Ream wrote: > > 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/2d32b799-0d8d-4ea7-b593-cfba3873af45o%40googlegroups.com.
