Bringing Emacs packages to Nyxt

[pdelfino]

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

I'm always frustrated with the fact that I can't use my beloved packages from Emacs in Nyxt. This is especially relevant because Nyxt shares so many similarities with Emacs.

Also, in parallel, Nyxt is working to support third-party browser extensions (e.g., bring Firefox's extensions to Nyxt). Although I have seen multiple discussions on the support of 3rd party extensions, I have not seen discussions on Emacs extensions being supported and I would like to have something similar for Emacs extensions/packages.

This is especially interesting because Emacs is written in Elisp and Elisp is approximately a subset of Common Lisp. However, the Emacs API can be messy and the mapping from Emacs to Nyxt is not perfect due to architectural differences, for instance, emacs' buffers do not have the same structure to easily map them as Nyxt buffers.

Describe the solution you'd like The main solution and the alternative are equally valid. The first option would be supporting the Elisp language in Nyxt's Common Lisp. In addition, it would be necessary to handle both the Elisp language being hosted in CL and the Emacs API translation to the Nyxt API.

Describe alternatives you've considered The alternative would be re-writing from scratch the main packages available in Emacs (Magit, org-mode, etc) in CL for Nyxt. It is unclear if this is going to be easier or harder than "simply" making "Emacs on CL", as described before.

Additional context This feature request started as a discussion in a private email and almost all the technical content and the hunches on how to tackle the problem come from a reply written by @ambrevar after a question I wrote. Errors and omissions are my responsibility.

[Ambrevar]

Thanks for posting this, @pdelfino !

I have a déjà-vu: wasn't this posted somewhere else already? Sorry if I'm mixing it up with something else, so much happened in very little time :)

[pdelfino]

I have a déjà-vu: wasn't this posted somewhere else already? Sorry if I'm mixing it up with something else, so much happened in very little time :)

I had a similar feeling... We discussed this more than 4 weeks ago via email. Initially, I thought I had already posted it. Then, I realized I did not do it in the past.

Then, I started suspecting that maybe another person (you or John) would have done it. Since I made some searching effort and could not find it, I ended up doing it.

[Ambrevar]

Some starting points:

• https://github.com/larsbrinkhoff/emacs-cl
• http://clocc.hg.sourceforge.net/hgweb/clocc/clocc/file/tip/src/cllib/elisp.lisp (some parts of Elisp in CL)

Some re-implementtions of Emacs in CL:

• https://github.com/burtonsamograd/med
• https://github.com/LaPingvino/Climacs
• https://github.com/earl-ducaine/clim-ed
• https://github.com/spacebat/lice

Maybe:

• https://github.com/emacsattic/xiomacs

Helpers:

• https://github.com/robert-strandh/Cluffer-Emacs-compatibility

[a1exsh]

I wonder how much effort it is to port Nyxt to Emacs Lisp instead? Any gut feeling? :)

[aadcg]

I'm not sure what you're asking, but Emacs' WebKit widgets seem to be not very reliable.

[a1exsh]

I'm not sure what you're asking, but Emacs' WebKit widgets seem to be not very reliable.

I know that there are existing web browser integration packages for Emacs (not sure how reliable). My thinking was, why not port Common Lisp parts to Emacs Lisp, while keeping the webkit or whatever actual rendering engine the same? How much work is that?

[aadcg]

There's a subset of Common Lisp available in Emacs Lisp, see cl-lib.el; and there's a subset of CLOS available via eieio.el.

I think this would be quite hard (and pointless as well, but that's a different issue) since you also have to deal with things like concurrency (which is supported in CL via bordeux-threads).

[aartaka]

I'm not sure what you're asking, but Emacs' WebKit widgets seem to be not very reliable.

I know that there are existing web browser integration packages for Emacs (not sure how reliable). My thinking was, why not port Common Lisp parts to Emacs Lisp, while keeping the webkit or whatever actual rendering engine the same? How much work is that?

Not possible, I believe. Elisp is

• single-threaded,
• dynamic-binding-everywhere language,
• and has an incomplete object system
  • I mean, yeah, EIEIO is a huge work and kudos to those that do it, but it is terribly incomplete and unsafe tompared to CLOS.

Our use cases require:

• At the very least two threads: renderer thread and Nyxt UI thread. The more the better, but two is a bare minimum. We're extremely concurrency-heavy. We can more to async-based computations, but that'd require rewriting all of Nyxt logic.
• Lexical bindings. We (at least @Ambrevar and myself) are quite biased towards functional programming and referntial transparency of our code, which dynamic bindings will simply destroy.
• CLOS with meta-object protocol. We already use several MOP-specified metaclasses and two of our own (user-class and interface-class), with #2537 vouching for more.

EIEIO would only support it if we start rewriting EIEIO itself, together with half of Elisp too. Switching from a more powerful language to a less powerful one is lots of hours of work lost for almost no gain.

It's easier to emulate Elisp in CL, if we're talking interop between those.

[a1exsh]

It's easier to emulate Elisp in CL, if we're talking interop between those.

Fair points, and, yes I guessed that concurrency model difference is going to be a blocker. Thanks for sharing your thoughts! :)

[aadcg]

I can't extract any meaningful conclusion from this thread. If someone wants to port functionality from Emacs to Nyxt, the best strategy is rather simple: write it yourself. The impedance mismatch isn't simply due to the language. Emacs and the Web specifications are radically different.