Neovim integration - Githubissues

aartaka commented 2 years ago

Is your feature request related to a problem? Please describe.

"Emacs is an OS only lacking a decent text editor", while Nyxt OS-specific text editor is practically non-existent. How about we leverage some reliable third-party editor for our editing needs? Neovim, for instance, has a nice RPC/sockets-based API the only dependency for which would be https://github.com/mbrezu/cl-messagepack.

Describe the solution you'd like

Make a neovim-mode subclassing our existing editor-mode infrastructure and making it an editor with configurable keybindings that will basically invoke Neovim commands under the hood, and change the visuals based on Neovim events.

Describe alternatives you've considered

Emacs integration via sockets/CLI, suggested by @Ambrevar (also see #125, #461).
- Emacs is quite slow for such a network-based communication, while neovim is quite fast, and it was designed exactly with this RPC-based workflow in mind!
Lem integration, as per https://github.com/lem-project/lem/issues/543.
- I'm unable to build Lem and thus cannot easily test the feasibility of integrating with it, although having a Lisp-based editor is definitely nice.
Improvind a built-in editor.
- Meeeeeeeh ¯\(°_o)/¯

aadcg commented 2 years ago

The idea is certainly interesting.

Personally, I don't think I'm ditching Emacs anytime soon so invoking an external editor is good enough.

aartaka commented 2 years ago

@aadcg, having an editor in Nyxt is yet another reason to make it a better OS and ditch Emacs xD

aartaka commented 2 years ago

Throwing this into the space: getting all the NVim APIs is as easy as:

(uiop:launch-program (list "nvim" "--listen" "127.0.0.1:6666"))
(usocket:with-client-socket (socket stream "127.0.0.1" 6666 :element-type '(unsigned-byte 8))
  (loop for byte across (messagepack:encode #(0 1 "nvim_get_api_info" #()))
        do (write-byte byte stream)
        finally (force-output stream))
  (messagepack:decode-stream stream))

And then it's pretty easy to generate Lisp functions based on that.

jmercouris commented 2 years ago

Another option, Monaco from VSCode, or Kakoune

aartaka commented 2 years ago

@jmercouris, there was nx-ace, if you remember :) Adding more configuration options to it would make it work perfectly as an editor mode!

jmercouris commented 2 years ago

Indeed, I just didn't want to add the JS to our repository, but now that we are using submodules, I don't see why we couldn't build it in!

Ambrevar commented 2 years ago

@aartaka I think you were referring to performance when we talked, and note that Neovim uses BSD (network) sockets, while Emacs uses Unix (kernel) sockets, and the latter are faster it seems. Not sure it matters though.

aartaka commented 2 years ago

@aartaka I think you were referring to performance when we talked, and note that Neovim uses BSD (network) sockets, while Emacs uses Unix (kernel) sockets, and the latter are faster it seems. Not sure it matters though.

Yeah, I guess that performance may be alright in both cases :)

aadcg commented 2 years ago

This is certainly interesting, but how do you see this coming about? Would it belong to nyxt, or to a future nyxt distribution?

aartaka commented 2 years ago

This is certainly interesting, but how do you see this coming about? Would it belong to nyxt, or to a future nyxt distribution?

I'd say it's more on the side of a distribution. Right now I'd make it an extension and it would work just fine as one.

aadcg commented 2 years ago

Ok, no more concerns from my side then!

shaunsingh commented 1 year ago

I've been using nx-ace for my text editing needs the past few days but its certainly a bit limiting

I think we can implement a basic "neovim gui" in nyxt, getting the GUI info from neovim.

https://github.com/stacksmith/captive-neovim may be a good start

jmercouris commented 1 year ago

I wonder if we could utilize a headless Emacs to do this. What is to stop us from embedding Emacs in Nyxt? As far as I understand it, it is just rendering a set of chars to a screen. I wonder if we could somehow wrap that display and just show that... there must be a way.

jmercouris commented 1 year ago

Like what if we wrote some elisp that takes the visible buffer and just outputs it as an HTML stream?

jmercouris commented 1 year ago

I mean there is this: https://github.com/karlicoss/cloudmacs

maybe we could do something similar... it could be a cool editor option.

jmercouris commented 1 year ago

Honestly as much as I hate JS, I think we should add xterm as a submodule and integrate it. https://xtermjs.org/

if that is a core mode, then we can easily have a "emacs -nw" type command for your editor.

aadcg commented 1 year ago

there must be a way

My understanding is that, theoretically, you can start emacsclient and establish the communication Nyxt <-> Emacs via IPC socket. Don't ask me the details, since I never tried to do it. But such a mechanism would have to be an extension. I don't think it makes sense to deliver Nyxt under the assumption that Emacs is available.

While this is interesting, I don't think that external-editor.lisp, at this point, is a lot worse. Conceptually it's radically different from the option mentioned in the paragraph above: calling an external editor opens an external window, while it would be nice to have a subset of the capabilities of the editor readily available in Nyxt's text input areas. Remark: notice that it's OK to deliver external-editor.lisp with Nyxt since it's general enough (unlike the idea of the 1st paragraph).

We should not forget that we depend on cluffer for our input buffers. On the other hand, we should also not forget that GUIs (like GTK) also have some primitives available.

It is my belief that, for our input buffers, we should depend on the primitives delivered by the GUI since it's his responsibility to handle the most important aspect of any text editor: re-displaying the contents. When we say need "we need a powerful text editor", I don't think we're being rigorous. We central part of text editing (re-displaying) is handled by the GUI. What we need, instead, is the capabilities of cursor movements that we expect from a powerful text editor. It's quite different actually. Perhaps, the wisest thing to do is to implement the advanced cursor movements in JS so that we don't deal directly with web renderers and GUI toolkits.

shaunsingh commented 1 year ago

There is https://gitlab.com/janneke/emacsy for scheme

If we're going to steer towards emacs, I feel like we should just go to lem and integrate it with editor-mode, either as a plugin or within nyxt. NYXT seems to shine most with javascript and common lisp, integrating an external tool is going to be tedious and impossible to fully bundle with nyxt.

Regarding a minimal terminal, https://github.com/3b/3bst seems like an option, or integrating a shell into repl-mode

aadcg commented 1 year ago

If we're going to steer towards emacs, I feel like we should just go to lem and integrate it with editor-mode, either as a plugin or within nyxt.

As a plugin, all ideas are valid.

Within Nyxt, I'm not sure whether that's a good idea. What we need is a library that assumes some primitives and implements cursor movements on top of those.

aartaka commented 1 year ago

Besides, Lem is not exactly cool build-wise, and I had a lot trouble trying to build it without Roswell :P

aadcg commented 1 year ago

Lem is not exactly cool build-wise

And it doesn't stop there.

In my opinion, the most interesting place to extract a library of cursor movements is Hemlock. The code base is really good from what I've seen.

aadcg commented 5 months ago

The topic for a Nyxt extension.

On this topic see https://github.com/scymtym/text.editing.

atlas-engineer / nyxt

Neovim integration #2248