[Matthias1]

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

[jcelerier]

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

[frankohn]

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.

[khaled]

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

[romwell]

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.

[jart]

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.

[jcelerier]

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

[jart]

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.

[jcelerier]

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.

[jdonaldson]

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.

[ComputerGuru]

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.

[jcelerier]

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

[ComputerGuru]

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.

[wiz21c]

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

[analognoise]

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

[contingencies]

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

[queuebert]

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?

[enticeing]

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/

[lr1970]

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

[bachmeier]

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.

[bityard]

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.

[MarcusE1W]

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)

[nikodunk]

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?

[Snetry]

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/#

[sigzero]

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.