It seems to me that many python-based systems could be run in a Leo process, which would give access to their internal APIs. The challenge would be to get their input and output into Leo cells.
For non-python systems, in some cases there could be a python wrapper that handles communication (i.e., the Leo Bridge could be wrapped to communicate with a node.js server, just as an example, though that goes in the opposite direction from what I am thinking of). To go this route, one challenge would be to abstract the new parts so that they can be adapted to new systems as easily as possible, without having to rewrite existing code (except of course for the adapters and wrappers). On Wednesday, February 21, 2018 at 9:26:42 AM UTC-5, Edward K. Ream wrote: > > On Wednesday, February 21, 2018 at 1:39:52 AM UTC-6, Edward K. Ream wrote: > > Indeed, standard Leo plugins could communicate with *external hosts* such > atom, vscode, jupyter notebooks, eclipse, jEdit, etc. Let's call these Leo > python plugins *external gui plugins*. These Leo plugins would > communicate with *host plugins* in the external hosts. Host plugins > could be written in javascript (atom, vscode) or java (Eclipse) or python > (jupyter). > -- 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
