The plugin system is a disaster in this project. Basically, each "plugin" is just a Lua script that can (and often does) modify absolutely anything in the editor, including core data structures and other plugins.

The original Lite was an exercise in creating a minimal editor, which I think succeeded. This project tries to take that base and expand it to add a ton of features, but doesn't re-architect it to support that expansion. So instead, you have a big bowl of Lua flavored spaghetti.

On the bright side though, it does seem like the maintainers are dedicated to keeping it working. So if you're looking for a text editor, you could do worse than Lite XL.

Honestly, the thing that made me step into this project was actually this plugin interface.

Adding support for halfway decent Perl syntax highlighting took literally 5 minutes with no familiarity with the editor at all, and not having used lua in years.

It was extremely straightforward and refreshing, compared to say, writing a plugin for something like Code::Blocks.

I'm not sure it's a bad thing that anything can be modified in Lua. One of the main reasons Emacs is so powerful is because almost anything can be customized in elisp. I haven't used Lite XL and this is just an uninformed general opinion.

Lua != Lisp. This distinction is quite important and often understated.

You can make a very customisable editor in a very flexible meta language like Lisp. If you do it in Lua, you have an absolute mess. I spent a few days studying Lite XL's source code before deciding the choice of language was going to be its downfall, unless they adopt very strict and well-documented interfaces.

I feel no one's trying to understand why Lisp was a thing and are doomed to try, and fail, to recreate Emacs in a subpar language. IMHO, neovim suffers from the same problem. Their choice of language is a very unstable foundation to build all those IDE-like features. vimscript is terrible, but was tailored for the problem at hand.

"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."

I'm not so sure about lua != lisp. You have lexical scoping and first class closures. Tail call optimisation and garbage collection. The compiler is present at runtime. A small core which is extensible in itself or native language, e.g. to swap out doubles for bignums. I think there's s expression syntax for it as a third party project.

You don't have macros as far as I can tell, though meta lua looks suspiciously close to it.

What parts of lisp do you see missing from this?

Meta programming. Code is data is code. First class macros. Lisp is an abstraction level or two above what can be done in Lua. Of course Lua is a Turing-complete language, but so is Brainfuck. The main thing is Lisp doesn't have a structure, so it can be and represent anything, a little like written text.

I do not want to sound condescending, I just hope to convince you to try something new: have you used a Lisp language before? Just knowing the syntax doesn't count. People have talked about it much more and much better than I can do in a comment.

If you haven't, no worries. I recommend a weekend with Racket. Then we can disagree that Lua is a worse choice than Lisp, but at least we will agree that the latter is infinitely more flexible and malleable.

Thanks for your reply! Wise to check assumptions.

Yes, written a compiler in common lisp and various toys in scheme. Spent some of yesterday porting functions from SRFI-1 to Shutt's Kernel which is pretty close to a lisp. Interesting that you claimed first class macros, they're usually second class in lisps.

I like scheme because I'm far enough down the compilers rabbit hole that language syntax looks like obfuscation in the way of the SSA representation. Writing the syntax tree directly is attractive there.

I find macros pretty confusing. Common lisp has straightforward behaviour but needs a lot of ceremony to make them reliable. Scheme's hygienic rewrites look simple but I don't understand the machinery behind them. Lexically scoped fexpr have obvious behaviour and implementation hence the interest in Kernel.

Which is to say I'm not disputing the lisp ~= lua premise from a position of total ignorance. The semantics look pretty similar to me. Lua doesn't have control over syntax, in (reader) macro sense, so perhaps it's metalua I should be equating to scheme. As above I'm not very focused on syntax.

I also write a lot of lua so am keenly interested in the distinctions I'm missing in the above.

Fair enough, you seem to be well informed so we can just agree to disagree.

And thanks for mentioning metalua, I had never heard of it! I know some lua but I'm far from being an expert, nor have I used it in anything larger than a few hundred lines.

I'm not the biggest fan of Common Lisp either, I too prefer the Scheme side of things though I don't think we haven't reached the golden standard yet (in my mind it would be a Clojure-like functional Lisp with first class support for actors, that compiles to native code)

That mutability is what Firefox XUL offered to extensions for many years, and when it was taken away there were — and still are — cries of outrage from devoted extensions users who expected to be able to modify anything.

So the model has lots of downsides, but certainly it’s not a dealbreaker.

This is the reason why I love it. Yes, it's not pretty, but you can hack anything into it really quickly. The fact that it's so 'informal' is the reason why it works so well imo.