The aim of Lite XL compared to lite is to be more user friendly, improve the quality of font rendering, and reduce CPU usage.
Plug-ins are not necessarily compatible
Plug-ins are not necessarily compatible
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.
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."
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?
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.
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.
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)
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.
So the model has lots of downsides, but certainly it’s not a dealbreaker.