back
75 comments
The community decided to work on a fork of it and extend it further: https://github.com/lite-xl/lite-xl
Any idea why it was forked?
rxi, lite's original author, considers lite to be complete, and isn't accepting new feature prs, which is fair enough.

lite-xl was forked to keep the same general principle of simplicity but going a bit further with features.

So, keep it simple, but make it juuuust a little bit more complicated?
Original lite is a clean and elegant Lua implementation of text editor with quite a few features. Lite-xl does the last mile to better integrate with OS and does many features that were out of scope of lite, for example multiple cursors. In that sense lite-xl is like you say a bit more complicated, to make it actually useful for everyday tasks.

I use lite embedded in my own application, and lite-xl as a quick and competent note-taking application (with custom plugin to set filename to date + document header). Both are great to me in their own ways.

Yeah, lol. It's a balancing act. Ideally we give it just enough juice to allow for things like native plugins, and the easy expected core stuff like nice font rendering , process management, multicursors, etc.. and then leave the rest to a really robust plugin ecosystem that wasn't possible to the same degree under lite.
There are many such projects, like Atom.io, whose support ends this year. I can't imagine this project will continue much further, even if I hope so. The only real open source project that is up today is Visual Studio Code, but that will continue to be maintained, I hope.

Edit: Oh wait, I forgot Eclipse... That heavy thing :P

> There are many such projects, like Atom.io, whose support ends this year. I can't imagine this project will continue much further, even if I hope so. The only real open source project that is up today is Visual Studio Code, but that will continue to be maintained, I hope.

What do you mean real open source project? I mean Linux is not going anywhere soon I'd say, or blender. Or are you talking about editors? There is Vim, Neovim and Emacs which all have shown that they will stick around for a while, so I really don't get what you mean.

I mean open source IDE's, real full featured developer environments for writing code. I don't talk about Open Source projects in general, but about competition for VS Code or Eclipse. There is something like Sublime Text, but it's not really open source and free.

Edit: With Vim and stuff I get your point, but I would say it's not really comparable to an UI-based IDE, it is command line stuff. Even if many people prefer that, it may not be as convenient as a GUI-based IDE for some of us.

Or am I missing something here? I really love(d) atom.io, but I need to find something else... (https://github.blog/2022-06-08-sunsetting-atom/)

> There are many such projects, like Atom.io, whose support ends this year. I can't imagine this project will continue much further, even if I hope so.

I think I get what you mean here: over time there have been many editors that might have contributed ideas to others, yet didn't quite make it themselves, due to either competition, failing to capture a significant market share, or any number of other factors.

In my eyes, this is especially prevalent in regards to browser based (e.g. Electron) editors.

Atom, which you mentioned, fits into this category: https://atom.io/

There was also Brackets, which similarly fell by the wayside: https://brackets.io/

Here, Visual Studio Code largely got a large market share and quickly displaced other options in the eyes of most developers: https://code.visualstudio.com/

Even in regards to native editors, there are many smaller projects.

CudaText: https://cudatext.github.io/

Geany: https://www.geany.org/

Lite: (which this post is about)

Here, however, there are more platform-specific options, and many older projects that are still going strong: Sublime Text, Notepad++, Vim, Emacs and so on. Not all of those are open source, though.

That said, while using a lesser known editor always comes with the risk that it'll be deprecated and won't see language integrations/features/plugins that you need, an editor's popularity isn't the only measure of success.

Some people don't mind using niche projects, because they feel comfy or fit their workflows well and that's good enough.

> The only real open source project that is up today is Visual Studio Code, but that will continue to be maintained, I hope.

I wouldn't say that the larger projects are the only "real" ones, though. Admittedly, it is also reasonable to generally go for the larger projects, if you want a more stable long term experience, though.

lite-xl just did a new release - it's still being actively developed, although only by a few people; but one of the focuses is the small & maintainable codebase.
That's quite nice. But wasn't that the point with Atom.io, too? But there was GitHub behind them. I will try lite-xl and I wish them the very best :)
I see the last release as January of this year. That's not "just did a new release" to me.
what are you talkign about? vim (and variants), emacs (and variants), vscode, vs community, eclipse, codeblocks, gnome builder, kdevelop, and probably a bunch more I can't think of.
Related:

Lite XL: A lightweight text editor written in Lua - https://news.ycombinator.com/item?id=28669439 - Sept 2021 (60 comments)

Show HN: Lite – A small, fast text editor - https://news.ycombinator.com/item?id=23126458 - May 2020 (256 comments)

Show HN: Lite – A lightweight text editor written in Lua - https://news.ycombinator.com/item?id=22987195 - April 2020 (3 comments)

Lite (and lite-xl) is an amazing little editor. I especially love how fast the program opens. There’s just a few small things that bother me enough to keep me from using it, but I remain impressed by the code and how lightweight it is.
Hey; I'm part of the dev community over at lite-xl; what're your top asks? I can see if we can throw it into the feature queue (though the queue is already pretty long).
Thanks for reaching out! At the moment I can't think of anything specific. It was just some small papercuts that added up enough to prevent me from using it regularly, not a lack of features. But lite-xl did show me that building a text editor isn't as difficult as I first thought, and I now have many ideas for my own personal editor that I might make one day. If I ever give lite-xl another try I'll be sure to share any requests
Fair enough; totally understand. If you ever can think of anything please don't hesitate to fire up an issue on the tracker. We're (very slowly) going through them.
Emacs standard/core key sequences (not just single keystrokes), e.g. C-x C-f to open files.
Exactly how fast is the startup time?

Faster than Sublime Text? Faster than gVim? Faster than Notepad.exe?

I don't like the word "fast" when it comes to describing the startup time of a text editor. Cold boot startup is a reasonable metric to benchmark reliably.

Some text editor out there is being marketed as "blazingly fast" because of the sole merit of the language they used to write it. But on a personal level, I found it to be as fast if not a bit slower than VS Code.

Here it opens faster than Sublime Text and much much faster than VSCode. Between Notepad and lite-xl I'd say the startup time difference isn't perceivable, and lite is far far more powerful.

It might not make a difference when using it as IDE - you fire it up in the morning and keep it opened. I use lite-xl as a second editor for occasional note entry and it starts up instantaneously. I found that using a second dedicated editor just for notes is excellent for window management and for cognitive context switching; I hated having notes buried somewhere in main editor tabs among open source code files.

Thank you for the recommendation. Just installed it is indeed fast. Will use it for a couple of weeks to see how things goes.

I have a separate 2009 ear 2 gb ram laptop which I am using as my note/comm device. I am using "mouse without borders" to control that device. I have a github repo as my note repo with VS code online. But I am looking for a better solution. I need to sync notes on both devices with vim bindings.

This is neat. I remember learning some Lua in order to write some custom Redis functions, and I was blown away by how handy of a language it can be. The indexing definitely tricked me a few times though.
Yeah; the indexing is weird when you're not used to it; but honestly I find starting arrays at 1 is actually incredibly useful for business logic. It's terrible for math, but it allows you to use things like truthiness really effectively for compound statements that return indices and stuff.

Like, for example, `string.find` returns the index where something's found. You can just do `if str:find("a")` if you want to test to see whether a string contains "a", whereas in most other languages that test for location you're required to check that the result isn't equal to `string::npos`, `null` (if your langauge supports that), `-1`, or some other value that's not 0. Lua, you can assume that it's truthy if it's found, because 1 is the start of the string, not 0.

Took me a while to get used to, but I really like the idiom now for things that just high-level string stuff, and glue code.

I don't mean to screw up the whole vibe of your comment, but...

    if 0 then
        print('0 is true')
    else
        print('0 is false')
    end
prints "0 is true". The reason why "you can just do `if str:find('a')`" is because it returns nil.

string.find never returns 0.

That's what I mean. It never returns 0, so is thus always truthy if it finds something.

If you do `if (str.indexOf("a"))` in javascript; you'll miss out on the case where the string starts with "a", because the index returned 0, which is falsy.

EDIT: Oh, sorry, I see what you mean. You're right, my bad.

EDIT2: I guess, let me rephrase. 0 is rarely returned for things, so the falsiness of it doesn't usually enter into the equation. So you can do things like that, regardless of the truthiness of 0, because it's not used, whereas in other langauges, you usually have to check, unless they have 0 as truthy as well. (though I guess this isn't much of an argument in favour of 1-indexes)

I've looked at this codebase and that of the XL version. Can a neone explain why there's C code there if it's meant to be lua? Genuine novice question. Thanks.
The other replies are correct, but there is a bit more to it.

Lua is a very small language with a tiny standard library. To extend it you write modules in C (or another language with bindings). This allows connecting the Lua code to various libraries. A notable example in lite is SDL. Without the C code in this repo the Lua code wouldn’t be able to use SDL for drawing or inputs

The C is mainly used to wrap the Lua interpreter, so that the editor can be distributed without the need for the user to have a compatible Lua interpreter installed.
No idea about this project in particular, but Lua is designed with C operability in mind. It's very easy to integrate the two languages together and this is often done so that you can have performance-constrained code written in C with higher level scripting done in Lua.
I would like to know more details about how the UI is build. So far I have found this [1]. A tutorial-like post will be welcome, though.

[1] https://rxi.github.io/lite_an_implementation_overview.html

The UI is done using an immediate rendering model.

It is entirely composed of two rendering operations, drawing solid color rects, or rendering text from a true type font.

You can read a bit about the underlying technology here: https://rxi.github.io/cached_software_rendering.html

It's quite brilliant.

Looks interesting. Especially in terms of its customisability, this reminds me a bit of Textadept, another Lua-based editor: https://orbitalquark.github.io/textadept/
So it uses SDL2 as a rendering engine. Does it roll its own widget library?
No; rxi wrote a rendering cache infront of the renderer. It doesn't require a widget library for this reason; it's able to efficiently implement an immediate renderer. Simplifies the codebase a lot.
If you are interested, the write up on the cached software renderer used in Lite is written up here: https://rxi.github.io/cached_software_rendering.html
I am using this editor for months now. Really happy, his strength is customization, the source code is so simple (c and lua). I have adapted it to my work perfectly, easier than (neo)vim or emacs.
This appears to be unmaintained.
Maintained & improved fork: https://github.com/lite-xl/lite-xl
So? It's a text editor. It's not like it's dependent on continued uptime of cloud services to function...
It is common for build time or runtime dependencies to change in incompatible ways meaning eventually you might not even be able to run it or even built it from source.
a dependency change is no longer an author's problem when they have pinned down versions.
> It's a text editor.

It's a code editor. Without Language Server support.

EDIT: fork does support it though https://github.com/lite-xl/lite-xl-plugins, proving the point

Even text editors can have security vulnerabilities that allow privilege escalation. Especially if they support plugins which this does.

To each their own, but I wouldn't risk it.