> > Here is my highest-level overview of the comparison between your work and > leoflexx.py (Leo in a browser). Please correct any misunderstandings.
Ok :) 1. The first fundamental task is to bridge the gap between the js side and > the python side. Indeed, Understanding that there was such a thing in Leo's source as '*leoBridge <https://leoeditor.com/leoBridge.html>*', and stumbling upon the *ap-to-p* and *p-to-ap* source code, is what made me start this project. along with this post : https://github.com/leo-editor/leo-editor/issues/1025 (I thought the current state of things was a month or two away! haha!). Also btw, it's in 'typescript' akin to coffescript and the like, so not technically 'javascript'. 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. It is with shame that I will admit to you that I have not looked into flexx enough to understand / acknowledge this. I have barely spent enough time and effort in flexx to get to those methods. 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. Yes, and what you referred to as 'text' is veeerrry sensible to being JSON, and not actually just 'text'. 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 not exactly right. That's where the /src/leoAsync.ts class comes into play: Some events may be initiated by Leo itself and so JSON messaging may sprout from the python side without being suspected as usual when just responding to a request initiated from the user's (vscode) side. But otherwise for user interaction its just do action->wait response from python. one by one, in a stack, no random order. use "await" to make all this asynchronous. Thank you python devs! I just followed the 'websocktets' documentation for a basic server that waits/responds to simple serial queries. 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. Being an integration into vscode, there is indeed, mostly just a ton of vs-code api shenanigans going on :) have not gone mad when trying to go about this api, yet... :) Vscode and Leo are the 2 coolest and useful tools in a programmer's arsenal. So I really enjoy discussing them! Félix On Monday, June 15, 2020 at 9:06:49 AM UTC-4, Edward K. Ream wrote: > > On Mon, Jun 15, 2020 at 1:09 AM Félix <[email protected] <javascript:>> > 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/d538d7f7-6917-4442-aefc-f440ee46dbe2o%40googlegroups.com.
