Something similar: Fennel (https://fennel-lang.org/) is a lisp that compiles into Lua, which neovim can use as plugins, so you can write neovim plugins in a lisp. Aniseed (https://github.com/Olical/aniseed) makes this really easy.

Aniseed is also used by Conjure (Interactive development environment for neovim, used for evaluating Fennel code inside of neovim), which is also made by the same author. Really great plugin for doing Clojure development with neovim. https://github.com/Olical/conjure

I've said this before but I think fennel is one of the most impressive languages around. Lua has a good reputation but I've used it professionally and find it one of the more practically painful languages to work in. Apparently fennel's author agrees, because fennel is laser-focused on correcting exactly its worst problems.

AND/BUT one of fennel's impressive things is that it sticks rigidly to lua runtime semantics. Which I found a little repulsive at first but has huge benefits in its context. You can drop fennel into any version of lua on any runtime (bc they vary a lot) and it works the same. You can hook the single-file fnl compiler into lua's module loader and mix fennel files into an existing lua program, freely sharing functions and metatables both ways.

Very flexible and powerful because of that tradeoff. Anywhere I have to use lua now I am actually using fennel.

The downside is this choice precludes it from having the clojure-like data structures and reference types. It could add a new standard library but doesn't, limiting itself to a handful of special forms (notably pattern match thank god) that mix nicely with the existing lua primitives. It looks like TimL has gone the other way with that decision, which I also appreciate. Makes it maybe a less flexible general-purpose lua replacement/extension, but probably makes it more powerfully suited for the specific purpose it'll be used for.

The same author also wrote Janet, which is also a nice language from what I’ve played around with. Especially the idea of forgoing Regex entirely and going with PEGs, as well as having “defs” inside functions bind local variables instead of “let” (though let is also idiomatic), very interesting. Small languages like that give a very nice feeling of learning them in a single day.

I looked into that language for exactly that reason and like it quite a lot. It's very good for scripting, though that is a crowded niche these days. It's also not much harder to integrate than lua, so I've used it a few times for an integrated scripting language when I didn't actually need a teeny tiny runtime.

And yeah you end up really missing PEGs in other languages. There are libraries, but having it built in is another thing especially with how well they fit into s-exp syntax.

* * *

I'll second Conjure. I use it for (Gerbil) Scheme, and it makes it so much better. I really wish there was better support for non-Emacs editors in the Lisp ecosystem. Or really just a stronger Lisp ecosystem...

Is there anything like this on the works for Vimscript 9?

Tangentially related: asking around in fora and in person, I was surprised to see that many plugin writers have had very good experience with the new Vimscript, and even prefer it to the more general purpose Lua (I was expecting the opposite). I myself have not used any Vimscript, but I am tempted to take a look at the new language.

There are things I'll never understand. Why would anybody do this? Why Clojure and not Emacs Lisp?

"There are things I'll never understand."

=> true

Hmm, that's

    > "There are things I'll never understand."
    "There are things I'll never understand."

for me. But

    > (cond ("There are things I'll never understand." 'true))
    true

works.

Seriously I'm glad to not understand everything, that would be quite worrying and/or boring.

Clojure is a language created and "controlled" by a single author (pretty unified overall) as a general purpose language, with implementations for multiple languages.

Emacs Lisp (elisp) is a language specifically created as a scripting language for an editor, maintained by an organization, with one compiler (AFAIK) and 99% of usage is within Emacs.

It's not hard to imagine people preferring Clojure before elisp, especially outside of Emacs.

To be honest, I would prefer Clojure to Elisp too.

But to be frank, it's hard for me to imagine people preferring Vim over anything that isn't ed ;). Although, at least using ed you don't need to type the colons :)

That would be awesome. Next step: run evil-mode on top of it.

We've come full circle.

because the author wants it?

Emacs lisp is a terrible lisp dialect. If it wasn't for Emacs' popularity it would have died decades ago. This is just one example in a long line of examples where nobody willingly implements Emacs lisp. Even in Emacs there is pressure to move towards Common Lisp.

Emacs lisp has, as far as I can tell, no advantages. It isn't especially good at text editing. It introduces differences from more popular lisp dialects. Anything it offers could be a library in some other lisp.

Clojure on the other hand, has a couple of nice syntax innovations and smooth default data structures.

Some people like Clojure syntax rather than S-expressions. Personally I don't get it, having arbitrary lists that require square instead of round brackets, arbitrary lists where pairs which belong together aren't grouped, and arbitrary lists where commas are interpreted as optional whitespace gives me a headache; but to each his own.

Clojure still uses S expressions, it just has more than just lists available. Square brackets don't make lists, they make vectors. Commas are always optional. I don't know what you mean by "arbitrary lists where pairs which belong together aren't grouped", but maybe you mean maps or sets, which are also not lists but a different data type.

  user=> (type [])
  clojure.lang.PersistentVector
  user=> (type '()) ; gotta quote the list
  clojure.lang.PersistentList$EmptyList
  user=> (type {})
  clojure.lang.PersistentArrayMap
  user=> (type #{})
  clojure.lang.PersistentHashSet

Different data types are used for different things. Vectors have more natural insertion behavior, so most people use them where that might happen.

  user=> (conj '(1) 2)
  (2 1)
  user=> (conj [1] 2)
  [1 2]

The example that most typifies my issues with Clojure syntax is let-binding. In Lisp it's very clearly structured:

  (let ((foo bar)
        baz
        (quux frob))
    ...)

In Clojure not only are the bindings unstructured, they are thrown into a vector. Not a list, not a map (for which Clojure has dedicated syntax, mind), a vector.

  (let [foo bar baz quux frob]
    ...)

And that is one of the only two places I know of where Clojure arbitrarily uses a vector when it uses lists everywhere else:

  (defn foo [bar] ...)

Instead of either of:

  (defn foo (bar) ...)
  [defn foo [bar] ...]

Any sufficiently complicated Vim configuration contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Emacs.

And its half doesn’t include the repetitive stress injuries ;)

> slow

There's quite a good chance that even the most complicated Neovim setup is faster than Emacs. Emacs lisp is notoriously slow, while Neovim uses LuaJIT, which is _very_ fast.

Emacs Lisp had native-comp now.

How do Neovim and Emacs startup times compare when using Emacs 28’s native compilation of elisp?

Obviously hard to compare because they don’t run the same packages but would still be interesting to see ballpark figures of setups with roughly equivalent functionality.

Are these startup times even significant enough to actually be noticeable anyway?

If people are bothered by Emacs startup times they usually just use Emacs Daemon. I let systemd start it for me at boop, for example.

Not favourably to Emacs.

Emacs now has an optimizing native code emitting compiler for elisp. It's definitely not slow, but not as fast a luajit.

Not sure why performance matters in this case anyways though.

A few years ago I would have hated you for this comment but after switching to Emacs, this comment is actually spot on.

I don't like Emacs and still thought it was funny :)

How difficult is it to write an "Emacs Lisp" interpreter in a foreign framwork like neovim? Wouldn't this basically convert any IDE into Emacs if the user wants it?

I mean, I know elisp is not the most efficient of Lisp compilers but doing so for a new IDE opens the door for all available codes and plugins people have written for emacs throughout the years.

I think a huge compatibility layer would also needs to be part of that. Most IDEs probably use a completely different vocabulary and set of concepts than Emacs, starting with buffers and mode lines and minibuffers and modes.

> Wouldn't this basically convert any IDE into Emacs if the user wants it?

Emacs Lisp is only part of the equation. You need the all of the programmability that implements 90% of Emacs in Lisp (all of the standard library functions, the display engine, etc).

This reminds me of a vim koan[0]:

> Master Pope once dreamt he was an Emacs user. When he awoke, he exclaimed:

> “I do not know if I am Tim Pope dreaming I am an Emacs user, or an Emacs user dreaming I am Tim Pope!”

---

0: https://blog.sanctum.geek.nz/vim-koans/

Can anyone see how to start the repl?

From the readme:

  Start a repl with :TLrepl. Tab complete is your friend. The first time may take several seconds (if your computer is a piece of shit), but compilation is cached, so subsequent invocations will be super quick, even if Vim is restarted.

For maximum effect, read the following in Tim’s distinctive voice:

“Is this a joke?

If you mean the 6,000 lines of working code, then no, I poured hundreds upon hundreds of very serious hours into that. But if you're referring to the fact it's woefully underdocumented, adds considerable overhead to an already slow host platform, and ultimately unlikely to gain any traction, then yeah, probably.”

ELVM might be a related project, which takes C code and compiles to various languages, including VIM.

https://github.com/shinh/elvm

Just in case you though VimL was too easy and want to add manual memory management in on top of it? ;)

If we implement TECO in this, do we break the Matrix?