On Mon, Jun 15, 2020 at 1:09 AM Félix <[email protected]> wrote:
I'ts been a pleasure to interact with the Leo's api! I wish vscode's api > was as documented and understandable as the one for Leo! > Glad you like it. leobridgeserver.py was coded in a leonine way in leoInteg.leo. I thought > this was important if I am to get a bit of 'Leo' coders to look into this > part of leoInteg in particular. :) > > (I personally would be curious to know what you think of the code in the > "*Outline > Edition Commands*" node because i'm not 100% sure I made good or > wrong/not-undoable operations in there...) > The best cool thing is that the js (vs-code) side can invoke any method of the leoBridgeIntegController class by name. This greatly simplifies the protocol. *About names* 1. It would be better to capitalize Leo the class name: LeoBridgeIntegController. This helps distinguish classes from instances. 2. In English, "Edition" is typically a noun. It would be clearer to call this node "Outline Editing Commands". 3. There is no such thing as a PNode in Leo. I suggest using, say, markAP instead of markPNode. The AP suffix makes clear that these methods take archived positions as arguments. *About undo* w_p is a position. Leo doesn't support undo on positions. Instead, Leo's commander (c) methods support undo. So if you want, say, markPNode to support undo, you should (*maybe*!) use code similar to c_oc.markHeadline. I say "maybe" because I'm not sure what the resulting interactions would be. Anyway, only commander methods support undo. Imo, each open outline in vs-code should have its own leoBridgeIntegController instance, and that instance should define c to be the commander returned by the call to controller.openLeoFile(path) in the bridge. Your code probably already defines per-commander instances. It might be possible to use vs-code handle undo in the body pane. But vs-code can't handle undo for outline-related commands. *Nits* 1. pyflakes complains that "os" is imported but not used. I always run pyflakes when saving files, so this is a bit annoying for me. 2. There is no need for @others in organizer nodes like "JSON Output Functions", and its following siblings. 3. There is no need for parens in "if(self.commander):". This js-like line appears in several places. As you correctly stated, leobridgeserver.py (which I often call "the server > script") is self-contained and agnostic towards any client that connects > to it. It could indeed be used *as-is* by any other Leo "integration" > projects. > That's great news. There is a lot of heavy lifting in leobridgeserver.py. It will be great to reuse the work. And not just for the code. leobridgeserver.py is a template (or target) for the editor-side work. > To dig more into the server/client relation and functionality: > /src/leoBridge.ts (which uses /src/leoAsync.ts) is the funnel through which > /src/leoIntegration.ts (the central hub of operations) interacts with the > server script. See the "Commands for leobridgeserver.py" part in > /src/constants.ts for the "actions" that the server supports so far. > Thanks for these tips. I'll study every line of code in leoBridge.ts, leoAsync.ts and leobridgeserver.py. And other files too. > I'll add more details as i post in this forum - don't hesitate to ask > about parts that interest you! :) > Thanks very much. I think I understand the big picture. Here is my highest-level overview of the comparison between your work and leoflexx.py (Leo in a browser). Please correct any misunderstandings. 1. The first fundamental task is to bridge the gap between the js side and the python side. flexx handles this with @action and @reaction decorators. In flexx, everything *looks* like python, but in fact everything on the js side is, perforce, javascript. In leoInteg, the leobridgeserver.py code (and the code that interacts with it) bridges the js/python divide. Only text can pass over the divide. vs-code knows nothing about Leo's classes. As a result, your js code must use AP's (archived positions), which are just text (json). AP's and related code are likely the biggest legacy of leoflexx.py. flexx simulates/allows arbitrary two-way interactions between the js and python sides. Your code gets the same effect with a *single* server. Requests flow from vs-code to Leo's bridge. Responses to those requests are the only data that need to flow in the other direction. You have shown that these messages suffice. It's super elegant to use "await" to make all this asynchronous. Thank you python devs! 2. The second fundamental task is to implement Leonine widgets. Flexx makes this easy with pre-built js widgets. I assume you use the vs-code api to create your Leonine widgets in vs-code. Edward P.S. I recently "rediscovered" Leo info issue #1015 <https://github.com/leo-editor/leo-editor/issues/1015>, LeoWapp theory of operation. I do recommend writing an theory issue for leoInteg as you go along. There is an amusing effect that happens often to me. I consider it to be a positive effect of forgetting details, which happens more and more the older I get :-) As I forget details, the bigger picture comes ever more clearly into focus. I say this is an "amusing" effect because it's easy to miss the biggest picture while documenting the details. You can see this in #1015. It doesn't explicitly mention the js/python divide! EKR -- 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/CAMF8tS2eTXMkhF-wY9W_bzXZLT5HR4xk3aH59Dq7yf%3DR0Mn5pA%40mail.gmail.com.
