Lite XL: A lightweight text editor written in Lua | Hacker News Reader

Lite XL: A lightweight text editor written in Lua

github.com

131 pointsasicsp60 comments

This seems to just be a fork of Lite[0] that supports better text rendering.

Lightweight GUI text editors are shocking hard to find. The primary reason I am not using Lite is the issues with Mac. So I’m definitely going to try using this.

[0]: https://github.com/rxi/lite

lightweight and "good text rendering" are by essence incompatible, you need at the bare minimum the unicode database somewhere which is already at least a couple dozen megs. Add to this freetype and harfbuzz if you want text rendering to be consistent across platforms, an emoji font because it's 2021, and we're nearing 40 megs just for being able to render random text properly

You are right here for the unicode part.

In term of quality of the text rendering I think we managed to be pretty good without introducing too much complexity or dependency, just the Freetype library. We chose a very specific approach where we completely bypass the OS API for font rendering and we render ourselves the text using the freetype library.

Otherwise, for the unicode part we are on the choice done by rxi. We support unicode but not every possible characters and we don't have, notably, support for Asian languages but we support russian, greek and some more unicode characters.

For the moment we choose not go for the harfbuzz library so we don't have support complex text layouts and we don't support ligatures. The problem is that harfbuzz bring quite a lot of dependencies and complexity.

In other term rxi chose a nice compromise to have most of the features needed by a coding editor with unicode support without bringing the huge complexity of having to support every possible language or text rendering features. With Lite XL we didn't deviate from this approach.

FWIW, libharfbuzz has no hard dependencies at all and it is fully functional when built with all optional dependencies disabled.

Are you the developer? Awesome!

Could you explain what the differences between Lite and Lite XL are? At a glance, they look about the same.

I've been porting Python to Cosmopolitan Libc so it can be an Actually Portable Executable and I managed to trim the entire UNICODE 13 and UNICODE 3.2.0 (b/c encodings.idna) databases down to 934kb.

    ~/cosmo$ bloat o//third_party/python/python.com.dbg | grep PyUnicode | grep -v '\b[bB]\b' | head
    000000000002e183 T _PyUnicode_Phrasebook
    0000000000028000 T _PyUnicode_CodeHash
    000000000001dc86 T _PyUnicode_Lexicon
    0000000000018780 T _PyUnicode_PhrasebookOffset2
    00000000000100a8 T _PyUnicode_LexiconOffset
    0000000000007d80 T _PyUnicode_Decomp
    0000000000006800 T _PyUnicode_DecompIndex2
    0000000000004dfc t _PyUnicode_RecordsIndex2_rodata
    0000000000004c68 t _PyUnicode_TypeRecordsIndex2_rodata
    0000000000004582 T _PyUnicode_ToNumeric
    000000000002e183 T _PyUnicode_Phrasebook
    ~/cosmo$ bloat o//third_party/python/python.com.dbg | grep PyUnicode | grep -v '\b[bB]\b' | awk1 | summy -x
    934,686

STB does a pretty good job at font rendering and it's less than 100kb. Fonts are pretty tiny too. Noto is under a meg if you just want western and emoji. Bloat is mainly an issue if you want to support China, Japan, and Korea who take up the lion's share of the UNICODE space, having at least 80,000 characters assigned to them. They also don't agree on how those characters should be rendered. So we need a separate copy of the font database for Japan, Korea, Hong Kong, China, and Taiwan. So you're actually looking at more than 40 megs. With Noto it's at least 66mb.

> STB does a pretty good job at font rendering and it's less than 100kb.

I'll be honest, I'll have a hard time taking the rest of your post seriously if you think that STB font rendering is anything close to good. It was maybe not too far from the 1997 state of the art but the world has moved on quite a bit since then, it's downright terrible if you are not going for "retro aesthetic" font rendering.

And all that stuff is patented so I have a hard time taking you seriously, who would sharply criticize a free public domain font rendering library over things it can't control. Retro aesthetic is my use case since I use stb_truetype to render fonts in a terminal. STB is scrappy and may not be Apple or Microsoft but it's been a remarkable gift from my point of view.

Thankfully I live in a free country where we can show the finger to software patents. Sorry if that is not your case, but I'd say that the problem to solve there is social and political.

> Retro aesthetic is my use case since I use stb_truetype to render fonts in a terminal

Just because it's a terminal doesn't mean it doesn't deserve proper hinting and proper AA. I don't understand in which universe this can be called "a pretty good job", it's doing barely more than the legal minimum. But then it's maybe a cultural difference speaking here, in my country it feels very very weird to be upbeat about things that are barely ok like US people seem to be a lot of time.

I'm not sure why we can't manage to ship a unicode database and an open text rendering library with every user-facing computing device. At minimum, we need something for text like libuv that gives a platform abstraction on top of the various cross platform libraries and resources that are already provided, so they're not recreated ad nauseam.

Your statement is only not incorrect because you couched it with "if you want text rendering to be consistent across platforms" but that really has nothing to do with anything. Every major desktop OS has native text rendering APIs that you can link against without shipping any additional dependencies, and they all work great if you're on the latest OS. Just use the native APIs and you don't need to reinvent the wheel.

> Just use the native APIs and you

cry because now your text is 2px longer on Mac than on Windows causing your paragraph to fold and breaking your layout and get user complaints that things aren't pixel-perfect between OSes. (if you never had that, well, you're a lucky person what else can I say ? for some it's a deal breaker.)

> and they all work great if you're on the latest OS

yes, I also have a few other kinks and fantasies. but for now, back to my macOS 10.9 and Ubuntu 14.04 users.

I can't tell if you're sarcastically agreeing with me or not, so in case you're actually serious:

> cry because now your text is 2px longer on Mac than on Windows causing your paragraph to fold and breaking your layout

Hopefully you don't expect everyone viewing this text file to only ever open it with the specific text editor make/model/version that you used to write it?

> back to my macOS 10.9 and Ubuntu 14.04 users.

Those operating system versions also provide more than acceptable text rendering that the users are already using for everything else on their system. Yes, the latest emoji won't render. But if that really bothered your users, they'd have upgraded.

Oh, I'm surprised. Isn't most of this provided by the operating system itself ? I thought so.

The wheel is rounder when we re-invent it in JS.

Haha. Added to taoup. https://github.com/globalcitizen/taoup

Since most people use only a fraction of the Unicode table, would it make sense to provide specific subsets as an on-demand download that is cached?

Textadept[1] is also quite nice, and configured (but not written) in lua. It seems to work fine in MacOS, but I haven't used it extensively.

[1] https://orbitalquark.github.io/textadept/

> Textadept[1] is also quite nice, and configured (but not written) in lua. It seems to work fine in MacOS, but I haven't used it extensively. [1] https://orbitalquark.github.io/textadept/

Straight from your link above:

> "... the editor consists of less than 2000 lines of C code and less than 4000 lines of Lua code."

So it is written in Lua and C (mostly for graphics widgets).

An important thing to note: It has similar customizability to Emacs, but you write your functions in Lua rather than Lisp. It's more than a text editor.

I'm not familiar with either project but "just a fork" does not seem to be an accurate description. Lite-XL has many more commits and seems to be much more actively maintained. Lite's last commit was about 10 months ago, the last release more than a year ago.

I have used lite-xl a bit and how I understand it is that lite-xl aims to add a few comfort functions for the user (PRs are accepted for that) and lite (without -xl) gives you a very minimalist experience. So whatever you prefer you can choose. (Next to the already mentioned rendering changes)

I agree and will try it to. Question - I couldn’t discern whether it has built-in terminal access? Or does that no longer qualify as lightweight?

There is a plugin[1] that adds terminals but Lite-XL still has a shaky plugin api for anything extensive

[1] https://github.com/benjcollins/lite-xl-terminal/#

I do not think it has it built-in. There is a console plugin for running commands but I do not think that is a full blown terminal either.

It's great to see lite on front page - such an incredible feat of engineering, making a cozy editor in less than 5k LoC of Lua (plus the C host). Robust text editing, syntax highlighting, command palette, pane splitting and management, plugin support and more. Writing plugins is simple and powerful.

The original lite and Lite XL are meant to run on desktops. I've recently started my own fork of lite[1] that allows it to run in VR environment. Once done I plan to use it as a competent editor for a VR-first development environment. I'm really digging the simplicity of Lua as a platform.

[1] https://github.com/jmiskovic/lite-lovr

This looks great! I've been looking for an open-source alternative to Sublime ever since the relatively underwhelming ST4 release.

An interesting one I found was CudaText (https://cudatext.github.io/), which has a lot of features and is a solid editor but... it's written in Free Pascal. That's not a technology I want to deal with for what would be my #1 tool.

I'll definitely be trying this out for myself soon, but it'd be helpful if you could include some side-by-side screenshots comparing the font rendering of your fork to the original, considering that's one of the main differences.

> but... it's written in Free Pascal. That's not a technology I want to deal with for what would be my #1 tool.

I didn't understand your point and would appreciate some more clarifications. For me, even if we ignore the fact that Pascal and its derivatives are 20+ year old mature languages, why does the programming language really matter if the tool built with it works to your satisfaction, and as intended?

In fact, Object Pascal (and not Pascal) with FreePascal + Lazarus IDE is actually a smart choice here as it allows you to develop multi-platform application easily with the same codebase. That is how CudaText is available for nearly all the popular platform (and even on some of the niche platforms e.g. xBSD OSes). Check out the open source Lazarus RAD IDE - https://www.lazarus-ide.org/ as it is a hidden gem for multi-platform development that not everyone is really aware of.

> why does the programming language really matter if the tool built with it works to your satisfaction, and as intended?

Because the reason I'm looking to move away from ST4 is because I was disappointed with the features and pace/direction of development. I want an open source text editor that I can customize however I want (and possibly embed in my projects), so something written in a language I have no interest in and/or dislike isn't going to work for me.

Does Lua differ in that regard? Lua seems to be tolerated (as a necessary evil, for certain definitions of "necessary") more than it is actively enjoyed. Not obvious why Object Pascal wouldn't be viewed the same and couldn't be treated the same.

Pascal was a big part of my learning to program (Turbo Pascal). Current day opinion on Pascal is that it's a dead language without much of an ecosystem. It's just the harsh truth.

Lua ended up as a "DSL" in a ton of places for general scripting applications etc. When I say "DSL" I get that it's not, I'm just generalizing as to the type of solutions that I've personally seen Lua leveraged. With this sorta "Lua in random places" bit I feel lots of us have ran into it.

When comparing Pascal to Lua I would be more comfortable with Lua for a modern solution - I would posit that very little greenfield development is happening in Pascal. Lua continues to be present in-industry.

This entire comment is anecdotal and based on personal experience.

Pascal became Object Pascal. Delphi is a dialect of Object Pascal and descendent of Turbo Pascal, and still here.

There are multiple compilers and IDEs that use Object Pascal such as Oxygene (RemObjects), Free Pascal/Lazarus, PascalABC (open-source on GitHub), Smart Pascal, DWScript, etc...

By the way, Object Pascal is mostly an extension of Pascal, so in many cases a Pascal programmer can transfer their code to the newer compilers/IDEs. Free Pascal/Lazarus even has a Turbo Pascal compatibility mode (in addition to Delphi compatibility mode).

Object Pascal is often ranked between #15 to #20 on TIOBE (and that's without counting some dialects). Lua is presently ranked #39. So if somebody is talking about popularity or who is the dead language, then they should be saying that about Lua, Rust, Julia, Kotlin, Haskell, etc... Those are all languages ranked far below Object Pascal.

> I would posit that very little greenfield development is happening in Pascal

This is a very good example of the importance of the power of branding - Pascal has actually continued to evolve over the past 50+ years, and even has a few ISO standards, but most don't know about it because of the name changes:

Pascal -> Clascal (Pascal with object oriented extensions) -> Object Pascal (more OOP extensions)

Clascal and Object Pascal were developed in consultation with the original developer of Pascal, Niklaus Emil Wirth, and Object Pascal enjoyed considerable commercial success with Apple, Microsoft and Borland. Niklaus Wirth however has a bad habit of changing the name of every evolution of Pascal he himself works on, and so we have:

Pascal -> Modula / Modula 2 -> Oberon (with extensions we also have Oberon 02 and Active Oberon)

Oberon is powerful even for system programming, and the creator himself used it to create a new OS with same name as the programming language (yet again showcasing that he has no concept of branding and marketing) - http://www.projectoberon.com/ .

That makes sense - I didn't consider that you may want to change the code yourself.

Free Pascal tech slaps.

Honestly it crushes just about...well, everything. There's even a JS transpiler, it's lightning fast, and it's beautiful.

If you evaluate it on its technical merits, it absolutely stomps. The community is AWESOME too - people just making things because they want to, not because it's some resume padding fad framework BS, there's a lot of people who understand the actual concepts and will talk to you about them.

It is beautiful, and amazing. A 5-10MB executable, just like you had in 1998. Lightning fast. BGRABitmap and BGRAControls? STOMP. https://wiki.freepascal.org/BGRAControls#BGRAVirtualScreen

Oh, you can draw natively just like you would on an HTML5 canvas, but without the overhead of a browser? https://wiki.freepascal.org/BGRABitmap_tutorial_14

FreePascal/Lazrus are practically a hidden weapon.

"but... it's written in Free Pascal. That's not a technology I want to deal with..."

I don't get where this thinking is coming from either. People have to be careful about self-serving corporate propaganda that big companies spew out against other programming languages they don't own or control.

Object Pascal (also known to some as Delphi) is extremely viable technology with a diverse range of compilers/IDEs, applications, and including open-source or freeware offerings.

Also, I find it funny when people then choose or get caught up in "lesser", "more difficult", or "limited" technologies. People would be doing themselves a favor to study up on Object Pascal or at least look at Wikipedia to get a clue.

>it'd be helpful if you could include

I'm not the author, just sharing the repo here. I'd suggest to open an issue.

The font rendering of Lite was the main issue of the editor last time I checked.

The project is impressively small and light, and quite snappy from what I can tell.

I am a bit reluctant to switch editor again as I am happy with Sublime Text 4 and I don't need to change, but I think the approach here might be superior.

I prefer using Lua than Python for configuration and customization.

Very nice work!

Many people are going to compare Lite XL to Sublime Text and VSCode so I would like to make a few comments about the comparison.

Sublime Text is a more mature and has more resources than Lite XL. As far as I know it has a team of engineers dedicated to its development. It makes for an excellent editor and it is hard for Lite XL to compete. To my eyes the main reasons one *may* want to use Lite XL over Sublime Text are:

1. because Lite XL is free software 2. because customizing Lite XL using Lua is quite easy and fun

If you are okay with being non free and you look at the features you may prefer Sublime Text and that's fine.

Personally I moved from Sublime Text to Lite XL just because it isn't free. It is not only a matter of the cost of the license but also about the fact of being free software.

If we speak about VSCode, it also has a ton of features more than Lite XL, a formidable set of plugins and growing and big company behind it with dedicated engineers so it is well placed to be much better than Lite XL. In reality, personally, I never used VSCode even before Lite XL, I was just using Sublime Text. The reasons I *personally* cannot tolerate to use VSCode is that:

- it is slow to start, and it starts incrementally - the UI it is somewhat flickering, in the syntax highlighting and in the menu (for linux only) - it has a ton of popups, bells and whistles that are annoying to me.

This is much a matter of personal preference. May people are tolerant to some slowness and some occasional flickering to have more features. In this case they may prefer VSCode and this is fine too.

I personally prefer when the editor gets out of the way being fast, responsive and still nice on the eyes. In addition it is free software and easy to hack and this is very important too.

Can you share with use what are the benefits of Sublime Text 4 over version 3? I bought the licence for 2 and 3, but struggle to find a reason to upgrade.

The LSP project brings it up to par with vscode for auto completed and introspection, the adaptive theme that lets you change the ui/color theme depending on what mode your OS is ok is also great.

Can you use Pylance with it?

I believe Pylance is closed source but based on the open source Pyright. There appears to be a plugin for using Pyright with Sublime Text: https://github.com/sublimelsp/LSP-pyright

Does this really warrant a fork? Couldn't better font rendering be merged into Lite? It's an interesting and quite new text editor. Getting traction for a new editor is hard, and having multiple forks seems like it could make it even harder.

Author of the Lite XL fork here. The reason why I started a fork of Lite is that rxi, the author of the original project, refused to merge my proposition to improve the font rendering. He didn't want to bring too much complexity to the project.

In more general terms the author or Lite, rxi, values a lot simplicity in term of coding implementation even when some things are unfriendly or annoying for the user. So my decision was to fork Lite to create an alternative project that has a different compromise between simplicity and user friendliness.

Now Lite XL has a small but awesome group of contributors to the project. We still value simplicity and we are trying to keep a good balance between features and complexity of the implementation but our main goal for the editor is to be friendly and useful as a general purpose coding editor.

I have a very high opinion of rxi. To me the original project, Lite, is a constant source of inspiration. Even if we have made a fork of its project we highly value the principles and software practices established by rxi.

Here's the full reasoning mentioned in the README:

>The aim of Lite XL compared to lite is to be more user friendly, improve the quality of font rendering, and reduce CPU usage.

Textadept is another lua-based text editor ( https://orbitalquark.github.io/textadept/).

After using vscode for a while, lite is amazingly fast. It is now my default editor for things that don't need a specific vscode extension.

I wish there was a lightweight GUI editor that supported LSP plus a few other IDE functions

There's an LSP plugin for this editor listed on one of their plugin pages (I think the external plugins page).

I've yet to try the editor or the plugin though.

One thing that bothered me about Lite editor, was that you couldn't change your working directory in Lite. Is this fixed/implemented in Lite XL?

Yeah, you can change the current folder with the `Core: Change Project Folder` command, and you can add/close folders with `Core: Add Directory` and `Core: Remove Directory`. (These are run with CTRL+SHIFT+P)

What was actually improved? Hinting? Using harfbuzz?

Lite XL use the freetype library for font rendering instead of the stb_truetype library.

Using the freetype library we do hinting but only in the vertical axis and subpixel rendering and positioning along the horizontal axis. This is the so called "slight" hinting and it was used with subpixel rendering.

The original Lite on the other side doesn't do any hinting and is not doing subpixel either, it just does grayscale rendering.

In order to reduce complexity in the main project, can’t you separate freetype into a tool that caches fonts as bitmap glyphmaps, and use the glyphmaps directly? That way, the editor itself doesn’t need to worry about that.

Looks like more complexity and that would prevent users from changing fonts in their preferences.

Right now, how does it work? Does it build a glyphmap everytime the editor starts?

Does this support multiple carets?

Yes.

Why?

Reply on news.ycombinator.com