5 ms·

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 no

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 https://github.com/rxi/lite

nikodunk 5y ago
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?
- sigzero 5y ago
  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.
- Snetry 5y ago
  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/# https://github.com/benjcollins/lite-xl-terminal/#
jcelerier 5y ago
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 5y ago
  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.
  - romwell 5y ago
    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.
  - khaled 5y ago
    FWIW, libharfbuzz has no hard dependencies at all and it is fully functional when built with all optional dependencies disabled.
- wiz21c 5y ago
  Oh, I'm surprised. Isn't most of this provided by the operating system itself ? I thought so.
  - analognoise 5y ago
    The wheel is rounder when we re-invent it in JS.
    - contingencies 5y ago
      Haha. Added to taoup. https://github.com/globalcitizen/taoup https://github.com/globalcitizen/taoup
- jdonaldson 5y ago
  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 5y ago
  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 5y ago
    > 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 5y ago
      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.
- queuebert 5y ago
  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?
- jart 5y ago
  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 5y ago
    > 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 5y ago
      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.
enticeing 5y ago
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/ https://orbitalquark.github.io/textadept/
- lr1970 5y ago
  > 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/ 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 5y ago
  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.
MarcusE1W 5y 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)
bityard 5y ago
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.

nikodunk 5y ago

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?

sigzero 5y ago
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.
Snetry 5y ago
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/# https://github.com/benjcollins/lite-xl-terminal/#

jcelerier 5y ago

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 5y ago
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.
- romwell 5y ago
  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.
- khaled 5y ago
  FWIW, libharfbuzz has no hard dependencies at all and it is fully functional when built with all optional dependencies disabled.
wiz21c 5y ago
Oh, I'm surprised. Isn't most of this provided by the operating system itself ? I thought so.
- analognoise 5y ago
  The wheel is rounder when we re-invent it in JS.
  - contingencies 5y ago
    Haha. Added to taoup. https://github.com/globalcitizen/taoup https://github.com/globalcitizen/taoup
jdonaldson 5y ago
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 5y ago
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 5y ago
  > 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 5y ago
    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.
queuebert 5y ago
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?
jart 5y ago
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 5y ago
  > 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 5y ago
    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.

enticeing 5y ago

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/ https://orbitalquark.github.io/textadept/

lr1970 5y ago
> 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/ 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 5y ago
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.

MarcusE1W 5y 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)

bityard 5y ago

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.