Using Neovim is hampered by it not being equally well supported on Windows as on Unix-y systems. There windows support consists of the core running with a Qt frontend. Terminal based Neovim only works well on Unix-y systems.
I believe the embedded switch is meant to be run with the terminal, it uses stdio/stderr as the communication channel between the parent and the embedded Neovim. On Tuesday, October 9, 2018 at 12:12:28 PM UTC-4, Kent Tenney wrote: > > I also think it would onbe great if Leo could use neovim for the editing > experience. > > This project > https://github.com/neovim/python-client > > says: > > You can embed neovim into your python application instead of binding to a > running neovim instance. > > >>> from neovim import attach > >>> nvim = attach('child', argv=["/bin/env", "nvim", "--embed"]) > > Not sure if that works with QT > > https://gitlab.com/Muream/neovim-pyqt > seems to subclass a QT class to provide neovim in a QT window > > > ++++++++++++++++++++++++ > import PyQt5.QtWidgets as QtWidgets > > class NeovimWindow(QtWidgets.QMainWindow): > > def __init__(self, nvim): > super().__init__() > self.nvim = nvim > > ++++++++++++++++++++++++++ > ++++++++++++++++++++++++++ > import sys > import PyQt5.QtWidgets as QtWidgets > import ui.window as _window > from neovim import attach > > def spawn_nvim(): > nvim_argv = ['nvim', '--embed'] > nvim = attach('child', argv=nvim_argv) > print(nvim) > return nvim > > def main(): > app = QtWidgets.QApplication(sys.argv) > nvim = spawn_nvim() > window = _window.NeovimWindow(nvim) > window.show() > app.exec_() > > if __name__ == '__main__': > main() > ++++++++++++++++++++++++++ > > > On Tue, Oct 9, 2018 at 10:17 AM 'tfer' via leo-editor < > [email protected] <javascript:>> wrote: > >> >> >> On Tuesday, October 9, 2018 at 4:48:06 AM UTC-4, Edward K. Ream wrote: >>> >>> On Mon, Oct 8, 2018 at 2:47 PM 'tfer' via leo-editor < >>> [email protected]> wrote: >>> >>> So one idea talked about here is to run the IDE as a separate, possibly >>>> browser based process. I propose an inversion of this, run Leo as the >>>> separate process, (Leobridge++), then leave all the fiddly UI bits (like >>>> completions), to what ever editor you're using as a graphical front end. >>>> >>> >>> It's an interesting dream. See below. >>> >>> Some of the work being done in VScode caused me to have the realization >>>> that such an integration may not be as hard as we thought it might be. >>>> Think of it this way, editors are built to work on files, well let Leo be >>>> the file system! All you need is a tree-like browser in your editor to >>>> get >>>> at the "files", ie Leo's nodes. >>>> >>>> Emacs, Vim, VScode all have tree-like file browsers, they just need to >>>> be "re-plumbed" to get Leo to open the selected node as if it were a file, >>>> (then save any edits back to Leo). It may even be possible to have that >>>> plumbing be very dumb, just ship the outline navigation commands to Leo >>>> and >>>> have it send the resulting outline tree to the editor to "paint" rather >>>> that duplicate all the outline handling code in the editor. >>>> >>> >>> This would be just the tip of the icebersig. One needs a way of running >>> python code from within the editor, and the python code must interact with >>> the re-plumbed outline pane. >>> >>> Yes there would be a lot of fiddly bits and duplication of Leo's logic >> to handle the outline tree *in the editor,* but I'm suggesting something >> different here. Let Leo handle all that and ship the current state of the >> of the outline pane to the editor as just data, so it is just concern with >> the rendering of it, much as we do when we hand off the outline pane data >> to QT. >> >> I made things too simple when I said Leo would act as the file system for >> the editor we hook it up to. It does that but also responds to commands, >> even synthetic keystrokes sent to it by the editor. It also responds to >> information request, e.g. "what language should I consider this node to be >> written in?". >> >> So we need a rpc channel between the two, neovim has one built in, they >> use one called 'msg-pack'. >> >> VScode is based on electron/node.js. Perhaps VScode could emulate one >>> end of a yoton connection. (I'm never sure whether it would be a >>> client or server.) This would be similar to the emacs/pymacs bridge >>> <http://www.google.com/url?q=http%3A%2F%2Fleoeditor.com%2Femacs.html%23controlling-leo-from-emacs-using-pymacs&sa=D&sntz=1&usg=AFQjCNH2Di1EzkkhFYQu4TOjtlZFGtW1VA>, >>> >>> which is just a few lines of elisp. >> >> >> Interestingly I find myself trying Emacs again, (with Evil-Mode for sane >> keybinding ;-), just to get Org-Mode. >> >> >>> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at https://groups.google.com/group/leo-editor. >> For more options, visit https://groups.google.com/d/optout. >> > -- 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.
