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.
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.
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.
Could you explain what the differences between Lite and Lite XL are? At a glance, they look about the same.
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.
> 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.
~/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.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.
> 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.
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).