Live data from Hacker News

Lite XL: A lightweight text editor written in C and Lua

lite-xl.com

121–130 of 151 posts

Re: Lite XL: A lightweight text editor written in C and Lua

#121
post #18

Earlier quoted context omitted.

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 th…

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."

Re: Lite XL: A lightweight text editor written in C and Lua

#122
post #53

Earlier quoted context omitted.

Last time I looked it was simple software rendering on an SDL windows. As simple as it goes. I was impressed by how fast it was given that software rendering should be quite slow, but these days CPU are so powerful that this might not be a problem A simple OpenGL renderer could be added with minimal efforts I think.

It's a bit more complicated to add the OpenGL renderer, because of subpixel font rendering. You need to sample the framebuffer to do it correctly in all cases, as well as a custom shader. It's on the list of things to do, but as you say, CPUs are generally powerful enough these days; so it's not super high-priority at the moment.

In most cases you should know the background color behind the text without sampling the buffer, or at least get an approximation or revert to grayscale AA when layering text on top of unknown background, but yeah I get the idea and it is an interesting trade off.

Re: Lite XL: A lightweight text editor written in C and Lua

#123

Earlier quoted context omitted.

Fast native running binaries will never be anachronistic

I'm not saying they won't still be around. They will just use lower level graphics libraries and be more free form. The days of the 'native' GUI widgets are over.

you might be right, even though I find it very depressing. Native UIs using stock elements in simple ways tends to create competent interfaces. Web and electron apps are often confusing bespoke messes.

Native-ish interfaces are still pretty prevalent on mobile though.

Re: Lite XL: A lightweight text editor written in C and Lua

#124

How does this compare to Sublime? I ask because that's my simple/fast editor of choice currently.

In my own experience, it's just as fast if not a tiny bit faster, but what it's _really_ good at is customisability. With sublime I tried once to write a small plugin for gofmt and go vet (I don't remember what was wrong with the existent ones), and I gave up because it was more complex than I anticipated. With Lite XL I did it in 10 minutes and about 20 lines of lua code (though I did use this other plugin, it's a kind of support for linters).

Whatever I wanted to do it felt like I can just open the config and hack on it. Sublime never felt this way.

Re: Lite XL: A lightweight text editor written in C and Lua

#126
post #18
post #6

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

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 th…

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.

Re: Lite XL: A lightweight text editor written in C and Lua

#128
post #121

Earlier quoted context omitted.

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 understan…

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?

Re: Lite XL: A lightweight text editor written in C and Lua

#129
post #121

Earlier quoted context omitted.

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 understan…

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 cl…

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.

Re: Lite XL: A lightweight text editor written in C and Lua

#130
post #110
post #103

Lite XL is a small miracle. I can only echo other comments calling it an "open source Sublime Text". It is at least as responsive as Sublime in my tests, and feels even more lightweight. The executable is only 385 kilobytes on Linux, with just a handful of extremely basic system dependencies (SDL, Lua, FreeType, PCRE). Sublime Text is now getting squeezed from "above" (by VSCode) and from "below" (by Lite XL), while…

Sublime has, I think, a relatively loyal user base that have gotten comfortable there and don’t really have much of a reason to leave unless for a big IDE for specific projects. The plug-in ecosystem, while clearly aged, still has activity and new developments including adapting the new LSP stuff pretty well, and has some damn committed authors/maintainers. I’ve been a comfortable user for a while now and enjoy knowi…

[deleted]
Post reply on HN