leoInteg: progress report

[Edward K. Ream]

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

[Félix]

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

[Edward K. Ream]

On Wednesday, July 22, 2020 at 12:13:31 AM UTC-5, Félix wrote:

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....

hoist and dehoist work. When I tried git-diff nothing happened. The vs code debug console contains:

(node:16044) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
(node:16044) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
vscode-customcss is active!
leoInteg startup launched in  2 ms
[leoBridge] JSON was invalid: Error in git-diff: no method found
[leoBridge] Unprocessed or unknown JSON received:  Error in git-diff: no method found

This is in dev at the latest commit: 12367017.

Edward

[Félix]

hmmm... the gitDiff from the command palette works, but its command 'Method name' string is gitDiff, not git-diff as the 'minibuffer/getCommands' reports...

Just made me realize: how can method names have dashes in them? woulnt that trigger a substraction? Goes to show i dont understand some parts of commands/commanders....

I'll see this in detail tonight after work :)

--

Félix

[Edward K. Ream]

On Wed, Jul 22, 2020 at 8:16 AM Félix <felix...@gmail.com> wrote:

hmmm... the gitDiff from the command palette works, but its command 'Method name' string is gitDiff, not git-diff as the 'minibuffer/getCommands' reports...

Just made me realize: how can method names have dashes in them? woulnt that trigger a substraction? Goes to show i dont understand some parts of commands/commanders....

This looks like a bug in bc.getCommands.  I'll fix it today and issue a PR.

Edward

[Félix]

Are method names just a matter of converting from kebab case to camel case? If so, I'll do it on vscode's side if I encounter a '-' symbol.

Surely I'm being over optimistic,as usual...
--
Félix

[Edward K. Ream]

On Wed, Jul 22, 2020 at 5:20 PM Félix <felix...@gmail.com> wrote:

Are method names just a matter of converting from kebab case to camel case? If so, I'll do it on vscode's side if I encounter a '-' symbol.

Surely I'm being over optimistic,as usual...

Yes, you can't assume such a correspondence. Check out the PR 89. It does the job.

Edward