Lite XL: A lightweight text editor written in C and Lua(lite-xl.com)
lite-xl.com
Lite XL: A lightweight text editor written in C and Lua
https://lite-xl.com/
150 comments
Sublime has, I think, a relatively loyal user base that have gotten comfortable there and don’t really have much of a reason to leave unless for a big IDE for specific projects. The plug-in ecosystem, while clearly aged, still has activity and new developments including adapting the new LSP stuff pretty well, and has some damn committed authors/maintainers.
I’ve been a comfortable user for a while now and enjoy knowing how to use my tool well enough to casually customise it.
That being said, I think you’re right. I’ve got my eyes on trying out the new developments in open source editors. This one is new to me
It seems like with LSP and tree-sitter, a critical mass of foundational infrastructure is now just available for everyone so that new development and innovation can focus on the interface and design. Not sure how much space that leaves for sublime.
Tree sitter came up in the sublime community forum recently and there was a hard “not gonna happen” from the developer team on the suggestion of any form of integration. From what I can tell, the sublime syntax engine is either lacking or the applications of it aren’t taking full advantage of it compared to tree sitter. And syntax awareness seems like an increasingly valuable tool in my hacking of my text editor. So yea, interesting time for text editors… who woulda thought for 2023.
I’ve been a comfortable user for a while now and enjoy knowing how to use my tool well enough to casually customise it.
That being said, I think you’re right. I’ve got my eyes on trying out the new developments in open source editors. This one is new to me
It seems like with LSP and tree-sitter, a critical mass of foundational infrastructure is now just available for everyone so that new development and innovation can focus on the interface and design. Not sure how much space that leaves for sublime.
Tree sitter came up in the sublime community forum recently and there was a hard “not gonna happen” from the developer team on the suggestion of any form of integration. From what I can tell, the sublime syntax engine is either lacking or the applications of it aren’t taking full advantage of it compared to tree sitter. And syntax awareness seems like an increasingly valuable tool in my hacking of my text editor. So yea, interesting time for text editors… who woulda thought for 2023.
The main pain point of Sublime has always been it's extensibility, or lack thereof. The program is very rigid, and the plugins can't do much.
Mainly when creating user interfaces, you can't have buttons (for example a "run" button), the only official UI components are the command palette where you search commands, and a "panel", which is basically a single separate text view.
Plugins such as the terminal plugin [1] uses this panel to show an interactive terminal, but anything you do, such as call another plugin, or simply search text, will remove your panel and replace it with another.
The only ways to create real UIs are with very ingenious workarounds, notable mentions being:
- The color picker plugin [2], which literally bundles a small native executable for each platform it runs, containing a color wheel, which the plugin will call, the user will select a color, and the program will close, returning the color code in its exit code, which the plugin is listening to.
- The debugger plugin [3] which has the most complex workaround I have seen using sublime's html capabilities. It uses the panel to show html elements, buttons with images, texts, lists, tabs, everything thorough this workaround. But again, try to search text and you loose it.
That's mainly where VSCode "won", although I still daily drive Sublime when I am not on a "full blown IDE".
[1]: https://github.com/randy3k/Terminus
[2]: https://github.com/weslly/ColorPicker
[3]: https://github.com/daveleroy/sublime_debugger
Mainly when creating user interfaces, you can't have buttons (for example a "run" button), the only official UI components are the command palette where you search commands, and a "panel", which is basically a single separate text view.
Plugins such as the terminal plugin [1] uses this panel to show an interactive terminal, but anything you do, such as call another plugin, or simply search text, will remove your panel and replace it with another.
The only ways to create real UIs are with very ingenious workarounds, notable mentions being:
- The color picker plugin [2], which literally bundles a small native executable for each platform it runs, containing a color wheel, which the plugin will call, the user will select a color, and the program will close, returning the color code in its exit code, which the plugin is listening to.
- The debugger plugin [3] which has the most complex workaround I have seen using sublime's html capabilities. It uses the panel to show html elements, buttons with images, texts, lists, tabs, everything thorough this workaround. But again, try to search text and you loose it.
That's mainly where VSCode "won", although I still daily drive Sublime when I am not on a "full blown IDE".
[1]: https://github.com/randy3k/Terminus
[2]: https://github.com/weslly/ColorPicker
[3]: https://github.com/daveleroy/sublime_debugger
So I think the ColorHelper plug-in[1] is a better example of the modern gui hack in sublime. Basically goes all in on the HTML engine (for popup windows) that ships with sublime. I haven’t used it myself (HTML), but as far as I understand, buttons can effectively have callback functionality through “links” to commands. Or something like that.
Which doesn’t seem too bad to be honest. The author of that plug-in has also written a markdown to HTML extension for the purposes of making it easier to use the HTML engine, and is what is used by the LSP ecosystem for popup windows.
But yea, honestly it’s a little strange to me that they don’t ship a basic GUI api that’s moderately flexible for things like buttons text and windows but uses their own GUI engine.
[1] https://packagecontrol.io/packages/ColorHelper
Which doesn’t seem too bad to be honest. The author of that plug-in has also written a markdown to HTML extension for the purposes of making it easier to use the HTML engine, and is what is used by the LSP ecosystem for popup windows.
But yea, honestly it’s a little strange to me that they don’t ship a basic GUI api that’s moderately flexible for things like buttons text and windows but uses their own GUI engine.
[1] https://packagecontrol.io/packages/ColorHelper
What Sublime is missing for me is more of what VS Code kind of has, a little bit more UI for some of its existing features, like installing plugins or if you get the ColorSublime plugin it would be nice if that had its own tab.
Sublime is coded in C++ unlike VS Code which is TypeScript and can be iterated through in an afternoon and expanded. So iterating the UI is insanely easier, even building custom things.
I think Electron proved we need an open spec for UIs and it needs to be designed to be a fully native UI that anyone from any language can pick up the library and have a powerful near native UI stack and if you switch languages you can keep your UI specification, I think of things like GLADE with Gnome (or was it GTK?) and such, but much more lightweight and specific to just UI.
Sublime is coded in C++ unlike VS Code which is TypeScript and can be iterated through in an afternoon and expanded. So iterating the UI is insanely easier, even building custom things.
I think Electron proved we need an open spec for UIs and it needs to be designed to be a fully native UI that anyone from any language can pick up the library and have a powerful near native UI stack and if you switch languages you can keep your UI specification, I think of things like GLADE with Gnome (or was it GTK?) and such, but much more lightweight and specific to just UI.
[deleted]
People grow very attached to their editors. I had a professor in university who paid 100$ every year for his subscription to
https://crisp.com/
which he used for email and notes. He has a windows workstation set up with KVM (because the department is Linux based) solely so that he can use Crisp.
Sublime could easily survive another 30 years in some reduced capacity.
https://crisp.com/
which he used for email and notes. He has a windows workstation set up with KVM (because the department is Linux based) solely so that he can use Crisp.
Sublime could easily survive another 30 years in some reduced capacity.
Slight tangent: it looks like Crisp is also available on Linux, according to their website.
It's actually a lovely editor. I've used it a few times in the past, and it's lightning quick, responsive and featherlike in terms of resource use, as if Sublime was open sourced. Lite XL doesn't have fancy features, no crazy plugins, it's just a great basic GUI editor.
If you want "Open Source Sublime" check out CudaText. Loads fast too. Plugins are Python (like Sublime Text) but whole thing is coded in FreePascal using Lazarus. It's really capable.
https://cudatext.github.io/
https://cudatext.github.io/
After reading your comment, I tried to setup a CudaText + LSP Plugin + Intelephense as I mainly develop in PHP. Unfortunately, my experience of LSP on CudaText is not as good as Lite XL.
Also, looking at its repository, CudaText currently only has 1 active contributor, which is a little worrying if I want to use it as my main text editor. I hope the community around CudaText become bigger because I think the concept is good, and I really hope CudaText can be on par with Sublime Text.
Also, looking at its repository, CudaText currently only has 1 active contributor, which is a little worrying if I want to use it as my main text editor. I hope the community around CudaText become bigger because I think the concept is good, and I really hope CudaText can be on par with Sublime Text.
which is exactly what i want in a text editor. If i need the IDE features, i'd switch over to vscode, or use intellij. For quick text editing work, like changing a config file or something, this is perfect.
I don't enjoy vscode (any more) and don't enjoy IntelliJ, so I'd hope to be able to use this for IDE things.
I'd like to see an alternative to LSP created for editors like this, now that Visual Studio Code has shown not to be open. I think it could be built upon Jupyter Kernels, which really pioneered the client server architecture of LSP.
My ideal IDE would be something I would also want to use for one-off editing of config files. I did this with TextMate back in the day.
I'd like to see an alternative to LSP created for editors like this, now that Visual Studio Code has shown not to be open. I think it could be built upon Jupyter Kernels, which really pioneered the client server architecture of LSP.
My ideal IDE would be something I would also want to use for one-off editing of config files. I did this with TextMate back in the day.
You're conflating LSP and VSCode. LSP is a completely open spec for things like autocomplete, syntax highlighting, symbol searching and so on. Any editor can use any LSP server and jetbrains is using it for new languages in their editors and fleet
VSCode is also completely open source. The only thing not "open" about it is the keys they use to make the final distributable. Even the VSCodium docs say as much. They literally just build the final distribution but with slightly different keys to point to their open source extension distribution website instead of the Microsoft one
VSCode is also completely open source. The only thing not "open" about it is the keys they use to make the final distributable. Even the VSCodium docs say as much. They literally just build the final distribution but with slightly different keys to point to their open source extension distribution website instead of the Microsoft one
On a surface level, this is true. Vast majority of the code that makes VS Code is MIT licensed.
But the configuration of what marketplace is used and what extensions have access to the privileged "proposed API" makes huge difference in what Microsoft/GitHub can provide as user experience and what other developers can do.
See this great post for detailed explanation how Microsoft created a closed ecosystem around VS Code https://news.ycombinator.com/item?id=32657709
But the configuration of what marketplace is used and what extensions have access to the privileged "proposed API" makes huge difference in what Microsoft/GitHub can provide as user experience and what other developers can do.
See this great post for detailed explanation how Microsoft created a closed ecosystem around VS Code https://news.ycombinator.com/item?id=32657709
I understand the difference in UX but I'm really not concerned with that. The code itself is all open source for the VSCode client and will probably remain that way. Extensions like Pylance are replaceable and the Python extension can already just use Jedi instead. Also I'm sorry but that article is really terrible in terms of both content and layout. In terms of content, its only real argument is the .Net fiasco and some issue with Gitpod that really doesn't matter. In terms of content, the page is utterly unreadable
I'm perfectly aware of what Microsoft could do in some distant future. But as is, for all intents and purposes, VSCode is open source
I'm perfectly aware of what Microsoft could do in some distant future. But as is, for all intents and purposes, VSCode is open source
> But as is, for all intents and purposes, VSCode is open source
... Except that if you use the source to make your own build, you lose the extension ecosystem that is one of VSC's major selling points. It is at best a worked example of tivoization.
... Except that if you use the source to make your own build, you lose the extension ecosystem that is one of VSC's major selling points. It is at best a worked example of tivoization.
You can easily just download the extension dist files and dump it in the extensions folder. Most extensions are open source too and VScode is not doing anything special with the extension files. They're mostly just JS. You lose out on the convenience of the marketplace but the open source version exists. If a maintainer doesn't have their extension on there, usually reaching out to them will have them upload it there too or as I mentioned, just clone the repo
The extensions are compatible, aren't they?
I think there's also a hacky way to let VSCodium access the VS Code extension marketplace, but I believe it's an EULA violation.
rm -fr ~/.vscode/*
cp -a ~/.vscode-oss/* ~/.vscode/
# Run VS Code, download extensions
cp -a ~/.vscode/* ~/.vscode-oss/
I think there's also a hacky way to let VSCodium access the VS Code extension marketplace, but I believe it's an EULA violation.
geany works well too
You might also like SciTE.
Here's another one with a very small footprint:
https://github.com/DigitalMars/med
It's the one I use every day. The executable on Windows is a little over a meg. It also works on Linux and Mac.
https://github.com/DigitalMars/med
It's the one I use every day. The executable on Windows is a little over a meg. It also works on Linux and Mac.
Med appears to be a command line text editor, while this is a gui text editor... different beasts entirely.
Med is a text-mode editor.
If you want a command-line text editor, try the classic ed [1] :-D This was a kind of editor you might have to use with a teletype that prints on paper.
[1]: https://linux.die.net/man/1/ed
If you want a command-line text editor, try the classic ed [1] :-D This was a kind of editor you might have to use with a teletype that prints on paper.
[1]: https://linux.die.net/man/1/ed
I use this kind of editor because it works remotely over a tty interface. It's a full screen editor. The increase in utility for a graphics mode text editor is not that great for a code editor, because code is monospaced.
I don't think they were claiming that GUI editors are better... more that they have different audiences and comparing them doesn't work well due to that.
'med' stands for 'Micro Emacs in D'. You're living the toolmakers' dream Walter, thanks for the link.
I've wanted to write a small text editor for a while - cause I feel like most editors don't fit my workflow - but I've been a bit too busy with work.
I don't really care about fancy features or extensions. Let me just create "tasks" (for compiling and such) and let me execute these tasks with a single button, then let me see the output from these tasks that eventually execute some application/compiler etc. That'll let me use it for any language and task.
I'd also preferably like to use I J K L as the cursor keys and toggle "Mode" (VIM style) with TAB.
And the whole thing should just run in your terminal, which can already render text nicely.
I don't really care about fancy features or extensions. Let me just create "tasks" (for compiling and such) and let me execute these tasks with a single button, then let me see the output from these tasks that eventually execute some application/compiler etc. That'll let me use it for any language and task.
I'd also preferably like to use I J K L as the cursor keys and toggle "Mode" (VIM style) with TAB.
And the whole thing should just run in your terminal, which can already render text nicely.
I actually authored something for this to work with my workflow on lite-xl (I compile a mid-sized C++ codebase on the regular).
It's still not really ready for release, but it's here, in case you're at all interested: https://github.com/adamharrison/lite-xl-ide ; it's a build system and debugger integration.
The build tasks don't run in a terminal however; they move over to a build window at the bottom of the editor. The execution, however, by default, runs in whatever terminal you want to configure, so the actual program output does dump to an external terminal. Unfortunately, there is no truly integrated terminal as of yet.
It's still not really ready for release, but it's here, in case you're at all interested: https://github.com/adamharrison/lite-xl-ide ; it's a build system and debugger integration.
The build tasks don't run in a terminal however; they move over to a build window at the bottom of the editor. The execution, however, by default, runs in whatever terminal you want to configure, so the actual program output does dump to an external terminal. Unfortunately, there is no truly integrated terminal as of yet.
Also been thinking this.
What I want from a text editor is:
- Like you said, running tasks with a button/keybind, easily customizable (Like I wanna open a config file, add a function/script, bind to key/create UI button, done, not make a "plugin" not compile an "extension" or anything like that)
- Fuzzy finding/search - ripgrep and fzf can do that, so just bundle those I guess, or write my implementation of those.
- Must start instantly, load files instantly, every action needs to takes at most 100 ms.
- Be a "portable application", i.e it sits in a folder with everything it needs and I can copy that folder to any computer and be up and running with exactly the same configuration.
and NOTHING else.
What I want from a text editor is:
- Like you said, running tasks with a button/keybind, easily customizable (Like I wanna open a config file, add a function/script, bind to key/create UI button, done, not make a "plugin" not compile an "extension" or anything like that)
- Fuzzy finding/search - ripgrep and fzf can do that, so just bundle those I guess, or write my implementation of those.
- Must start instantly, load files instantly, every action needs to takes at most 100 ms.
- Be a "portable application", i.e it sits in a folder with everything it needs and I can copy that folder to any computer and be up and running with exactly the same configuration.
and NOTHING else.
This is also my general hope for lite.
- Configs in lite are all done in lua files, and there are two files that you can edit without ever having to create a plugin that are automatically loaded by the editor: your system wide user config (a lua file), and a project file (.lite_project). Both of these can bind keys, create buttons, add functions, and whatever you like, really.
- Fuzzy finding we can do, but it's not great. We're doing some work on this, but at the moment, we'll probably disappoint you.
- We should start pretty instantaneously on a vanilla config, though for large directory trees, there's an architectural issue that does make us take a bit longer, that hopefully will be resolved in a release or two. So if you have a smaller directory tree, then lite should be pretty quick; if it's large, perhaps hold off looking at it.
- lite offers fully portable releases, and infact, I have an all-in-one build that bundles everything into a single, mostly statically linked executable; it's generally very flexible about how things are deployed.
We tend to add almost all extra functionality via plugins; so if you don't want a particular feature, you can simply remove the plugin, and be done with it.
- Configs in lite are all done in lua files, and there are two files that you can edit without ever having to create a plugin that are automatically loaded by the editor: your system wide user config (a lua file), and a project file (.lite_project). Both of these can bind keys, create buttons, add functions, and whatever you like, really.
- Fuzzy finding we can do, but it's not great. We're doing some work on this, but at the moment, we'll probably disappoint you.
- We should start pretty instantaneously on a vanilla config, though for large directory trees, there's an architectural issue that does make us take a bit longer, that hopefully will be resolved in a release or two. So if you have a smaller directory tree, then lite should be pretty quick; if it's large, perhaps hold off looking at it.
- lite offers fully portable releases, and infact, I have an all-in-one build that bundles everything into a single, mostly statically linked executable; it's generally very flexible about how things are deployed.
We tend to add almost all extra functionality via plugins; so if you don't want a particular feature, you can simply remove the plugin, and be done with it.
Certainly Vim has all of the Makefile machinery built-in and it wouldn't take much to customize it [1].
[1]: https://vimways.org/2018/runtime-hackery/
[1]: https://vimways.org/2018/runtime-hackery/
Sounds like all you need is à plugin to call makefile targets from vim.
That is a method I've been toying with. But it's still such as hassle to quickly prototype something this way.
It's also near impossible to get I J K L working as the cursor keys in VIM without having some major interference.
It's also near impossible to get I J K L working as the cursor keys in VIM without having some major interference.
I haven't used it but there is :make which works with a Makefile.
Maybe you’d have more success with Emacs?
You could write elisp functions for your tasks and bind them to your prefered keys, with or without Evil.
You could write elisp functions for your tasks and bind them to your prefered keys, with or without Evil.
Actually, using Org mode and the Hyperbole package in Emacs solves all the problems listed in easy to use ways except you get much more editing dunctionality rather than just the features requested. Don’t reinvent the wheel; just learn something that runs everywhere and solves your problems. You start Emacs once and then rapidly edit files from the command-line by calling emacsclient, not restarting Emacs.
Emacs is a great software ecosystem, with a very.flexible editor built in.
With evil-mode, there's no excuse not to try it even if you find Vim's way of controlling input superior (which it as well may be).
With evil-mode, there's no excuse not to try it even if you find Vim's way of controlling input superior (which it as well may be).
I built something which scratches that basic itch, though my taste differs from yours:
https://www.github.com/marssaxman/ozette.git
I've used this for both hobby projects and professional work, over the years (though I often find myself using VSCode these days).
https://www.github.com/marssaxman/ozette.git
I've used this for both hobby projects and professional work, over the years (though I often find myself using VSCode these days).
Uses SDL for rendering the UI. While it makes it work cross-platform it unfortunately means it won't look like a native application. Then again, I don't think there's a C library which provides cross-platform native UI, only the Lazarus toolkit for Free Pascal and WxWidgets for C++.
"Native" means compiled code (likely C/C++/Rust/Zig) for some.
And it means using platform-specific UI widget for others.
I don't care too much about the UI widget style as long as the implementation is good and responsive. I tend to use app in fullscreen (F11) with minimal chrome and to be honest I kind of like when each app has its own UI style, especially if it can be user-configured with themes.
Apple/macOS users tend to fall in the other category, following the Apple guidance, where all apps should look like they were made by the same company.
I don't care too much about the UI widget style as long as the implementation is good and responsive. I tend to use app in fullscreen (F11) with minimal chrome and to be honest I kind of like when each app has its own UI style, especially if it can be user-configured with themes.
Apple/macOS users tend to fall in the other category, following the Apple guidance, where all apps should look like they were made by the same company.
> following the Apple guidance, where all apps should look like they were made by the same company
Mac users don't want all GUI apps to look alike; however, they should follow macOS UI/UX guidelines regarding copy/paste, drag and drop, keyboard conventions, etc. The whole point is to not have users having to relearn these basics for every new application.
Developers generally get these conventions "for free" by using the frameworks built-in to macOS. That doesn't prevent developers from creating custom, stylized interfaces if that's what's needed.
Even Apple's pro apps (Final Cut, Logic, etc.) look quite different from those that are bundled with macOS such as iMovie and Garageband.
Mac users don't want all GUI apps to look alike; however, they should follow macOS UI/UX guidelines regarding copy/paste, drag and drop, keyboard conventions, etc. The whole point is to not have users having to relearn these basics for every new application.
Developers generally get these conventions "for free" by using the frameworks built-in to macOS. That doesn't prevent developers from creating custom, stylized interfaces if that's what's needed.
Even Apple's pro apps (Final Cut, Logic, etc.) look quite different from those that are bundled with macOS such as iMovie and Garageband.
I wonder if people actually remember how native apps are supposed to look like on any of the major platforms…
Mac users, maybe. For all other platforms, churn and barely contained web apps are really wreaking havoc on the benefit of a uniform look and – most importantly – feel.
I'm a KDE user who really likes the classic Oxygen theme, and it's annoying when certain applications (e.g. Eclipse) just look way out of place. I managed to find a decent GTK port of the theme so even Emacs and Firefox are quite well-behaved.
No idea what a Windows app looks like, though, I recently fixed my grandfather's Windows 8 laptop and immediately gave up trying to understand how theming is meant to work.
No idea what a Windows app looks like, though, I recently fixed my grandfather's Windows 8 laptop and immediately gave up trying to understand how theming is meant to work.
(As another KDE user) I'll second this. Electron-based apps seems to be the worst culprits -- ignore my preference settings for max/min/close buttons, frequently do away with the title bar altogether leaving me with no window resize/move and hiding away Application/Window settings options, no regard for themeing,... it's become a significant (read: near deal-breaker) for me trying out new apps.
The massive changes in native UIs look and feel over the last couple decades really has made me double down on the CLI as the best interface. The CLI and the terminal are well established UIs with no big changes in a long time. The last big development I can think of is the use of sub-commands in addition to the normal command line call parameters.
I now focus on making my shell/terminal environment as good as possible and ignore GUI land whenever possible. Which today pretty much means 99% of the time I'm running a bunch of terminals and a couple web browsers.
I now focus on making my shell/terminal environment as good as possible and ignore GUI land whenever possible. Which today pretty much means 99% of the time I'm running a bunch of terminals and a couple web browsers.
Visually it's not that different, of course, but I don't see a more unified interface in the terminal these days. The Amiga might have had it, with its TRIPOS arg parsing, and of course you got your language-integrated text UIs like Oberon.
But beyond that, it's a mirror of the graphical side. I mean, it's not like the GUI invented a lot of new widgets, either. There are still buttons and menus, it's just that they look and behave differently in each app. The same goes for the CLIs, where there's no rhyme or reason for all the long/short parameters, sub-commands etc.; To use the git metaphor, we're in a bathroom where all the porcelain is coming from different manufacturers and your got your brutalist toilet bowl next to your gold plated sink. And nobody knows what to do with the three shells.
But beyond that, it's a mirror of the graphical side. I mean, it's not like the GUI invented a lot of new widgets, either. There are still buttons and menus, it's just that they look and behave differently in each app. The same goes for the CLIs, where there's no rhyme or reason for all the long/short parameters, sub-commands etc.; To use the git metaphor, we're in a bathroom where all the porcelain is coming from different manufacturers and your got your brutalist toilet bowl next to your gold plated sink. And nobody knows what to do with the three shells.
> Then again, I don't think there's a C library which provides cross-platform native UI, only the Lazarus toolkit for Free Pascal and WxWidgets for C++.
libui seemed like it was going to be this, but it looks like there haven't been commits in almost 2 years :(
(I'm mostly replying to raise visibility on libui, maybe someone will discover it/help out a bit)
libui seemed like it was going to be this, but it looks like there haven't been commits in almost 2 years :(
(I'm mostly replying to raise visibility on libui, maybe someone will discover it/help out a bit)
There's now libui-ng [1] which seems to be active and already has many wrappers
[1] https://libui-ng.github.io/libui-ng/
[1] https://libui-ng.github.io/libui-ng/
Native UIs are becoming an anachronism pretty fast. Free-form web and electron based apps are becoming the norm and it won't be to long before people see native UI apps as some sort of weird throwback.
IE. IMO that ship has sailed and using lower level/cross platform graphics stacks make a lot more sense these days.
IE. IMO that ship has sailed and using lower level/cross platform graphics stacks make a lot more sense these days.
Fast native running binaries will never be anachronistic
I'm not saying they won't still be around. They will just use lower level graphics libraries and be more free form. The days of the 'native' GUI widgets are over.
you might be right, even though I find it very depressing. Native UIs using stock elements in simple ways tends to create competent interfaces. Web and electron apps are often confusing bespoke messes.
Native-ish interfaces are still pretty prevalent on mobile though.
Native-ish interfaces are still pretty prevalent on mobile though.
"cross platform graphics stacks make a lot more sense"
Oh how they laughed when Sun tried this with Java some 25 years ago...
Oh how they laughed when Sun tried this with Java some 25 years ago...
So, is it actually small or is it just small on top of large libraries which do the heavy-lifting? I mean, ok, not Electron, but an Electron-based editor could also claim it was "small".
Is there a lightweight/fast editor that has native support for LSP? Is it even feasible to have a "native LSP editor" that doesn't rely on a plugin system, or is LSP so open-ended that you're always going to need some scripted support in the editor to make a particular language server work well? I'm thinking something akin to nvi or nano with LSP features added on.
You might want to check the helix editor. It has LSP support out of the box.
https://github.com/lapce/lapce is not stable but already looks impressive.
The aim of Lite XL compared to lite is to be more user friendly, improve the quality of font rendering, and reduce CPU usage.
Plug-ins are not necessarily compatible
Plug-ins are not necessarily compatible
The plugin system is a disaster in this project. Basically, each "plugin" is just a Lua script that can (and often does) modify absolutely anything in the editor, including core data structures and other plugins.
The original Lite was an exercise in creating a minimal editor, which I think succeeded. This project tries to take that base and expand it to add a ton of features, but doesn't re-architect it to support that expansion. So instead, you have a big bowl of Lua flavored spaghetti.
On the bright side though, it does seem like the maintainers are dedicated to keeping it working. So if you're looking for a text editor, you could do worse than Lite XL.
The original Lite was an exercise in creating a minimal editor, which I think succeeded. This project tries to take that base and expand it to add a ton of features, but doesn't re-architect it to support that expansion. So instead, you have a big bowl of Lua flavored spaghetti.
On the bright side though, it does seem like the maintainers are dedicated to keeping it working. So if you're looking for a text editor, you could do worse than Lite XL.
Honestly, the thing that made me step into this project was actually this plugin interface.
Adding support for halfway decent Perl syntax highlighting took literally 5 minutes with no familiarity with the editor at all, and not having used lua in years.
It was extremely straightforward and refreshing, compared to say, writing a plugin for something like Code::Blocks.
Adding support for halfway decent Perl syntax highlighting took literally 5 minutes with no familiarity with the editor at all, and not having used lua in years.
It was extremely straightforward and refreshing, compared to say, writing a plugin for something like Code::Blocks.
I'm not sure it's a bad thing that anything can be modified in Lua. One of the main reasons Emacs is so powerful is because almost anything can be customized in elisp. I haven't used Lite XL and this is just an uninformed general opinion.
Lua != Lisp. This distinction is quite important and often understated.
You can make a very customisable editor in a very flexible meta language like Lisp. If you do it in Lua, you have an absolute mess. I spent a few days studying Lite XL's source code before deciding the choice of language was going to be its downfall, unless they adopt very strict and well-documented interfaces.
I feel no one's trying to understand why Lisp was a thing and are doomed to try, and fail, to recreate Emacs in a subpar language. IMHO, neovim suffers from the same problem. Their choice of language is a very unstable foundation to build all those IDE-like features. vimscript is terrible, but was tailored for the problem at hand.
"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."
You can make a very customisable editor in a very flexible meta language like Lisp. If you do it in Lua, you have an absolute mess. I spent a few days studying Lite XL's source code before deciding the choice of language was going to be its downfall, unless they adopt very strict and well-documented interfaces.
I feel no one's trying to understand why Lisp was a thing and are doomed to try, and fail, to recreate Emacs in a subpar language. IMHO, neovim suffers from the same problem. Their choice of language is a very unstable foundation to build all those IDE-like features. vimscript is terrible, but was tailored for the problem at hand.
"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."
I'm not so sure about lua != lisp. You have lexical scoping and first class closures. Tail call optimisation and garbage collection. The compiler is present at runtime. A small core which is extensible in itself or native language, e.g. to swap out doubles for bignums. I think there's s expression syntax for it as a third party project.
You don't have macros as far as I can tell, though meta lua looks suspiciously close to it.
What parts of lisp do you see missing from this?
You don't have macros as far as I can tell, though meta lua looks suspiciously close to it.
What parts of lisp do you see missing from this?
Meta programming. Code is data is code. First class macros. Lisp is an abstraction level or two above what can be done in Lua. Of course Lua is a Turing-complete language, but so is Brainfuck. The main thing is Lisp doesn't have a structure, so it can be and represent anything, a little like written text.
I do not want to sound condescending, I just hope to convince you to try something new: have you used a Lisp language before? Just knowing the syntax doesn't count. People have talked about it much more and much better than I can do in a comment.
If you haven't, no worries. I recommend a weekend with Racket. Then we can disagree that Lua is a worse choice than Lisp, but at least we will agree that the latter is infinitely more flexible and malleable.
I do not want to sound condescending, I just hope to convince you to try something new: have you used a Lisp language before? Just knowing the syntax doesn't count. People have talked about it much more and much better than I can do in a comment.
If you haven't, no worries. I recommend a weekend with Racket. Then we can disagree that Lua is a worse choice than Lisp, but at least we will agree that the latter is infinitely more flexible and malleable.
Thanks for your reply! Wise to check assumptions.
Yes, written a compiler in common lisp and various toys in scheme. Spent some of yesterday porting functions from SRFI-1 to Shutt's Kernel which is pretty close to a lisp. Interesting that you claimed first class macros, they're usually second class in lisps.
I like scheme because I'm far enough down the compilers rabbit hole that language syntax looks like obfuscation in the way of the SSA representation. Writing the syntax tree directly is attractive there.
I find macros pretty confusing. Common lisp has straightforward behaviour but needs a lot of ceremony to make them reliable. Scheme's hygienic rewrites look simple but I don't understand the machinery behind them. Lexically scoped fexpr have obvious behaviour and implementation hence the interest in Kernel.
Which is to say I'm not disputing the lisp ~= lua premise from a position of total ignorance. The semantics look pretty similar to me. Lua doesn't have control over syntax, in (reader) macro sense, so perhaps it's metalua I should be equating to scheme. As above I'm not very focused on syntax.
I also write a lot of lua so am keenly interested in the distinctions I'm missing in the above.
Yes, written a compiler in common lisp and various toys in scheme. Spent some of yesterday porting functions from SRFI-1 to Shutt's Kernel which is pretty close to a lisp. Interesting that you claimed first class macros, they're usually second class in lisps.
I like scheme because I'm far enough down the compilers rabbit hole that language syntax looks like obfuscation in the way of the SSA representation. Writing the syntax tree directly is attractive there.
I find macros pretty confusing. Common lisp has straightforward behaviour but needs a lot of ceremony to make them reliable. Scheme's hygienic rewrites look simple but I don't understand the machinery behind them. Lexically scoped fexpr have obvious behaviour and implementation hence the interest in Kernel.
Which is to say I'm not disputing the lisp ~= lua premise from a position of total ignorance. The semantics look pretty similar to me. Lua doesn't have control over syntax, in (reader) macro sense, so perhaps it's metalua I should be equating to scheme. As above I'm not very focused on syntax.
I also write a lot of lua so am keenly interested in the distinctions I'm missing in the above.
Fair enough, you seem to be well informed so we can just agree to disagree.
And thanks for mentioning metalua, I had never heard of it! I know some lua but I'm far from being an expert, nor have I used it in anything larger than a few hundred lines.
I'm not the biggest fan of Common Lisp either, I too prefer the Scheme side of things though I don't think we haven't reached the golden standard yet (in my mind it would be a Clojure-like functional Lisp with first class support for actors, that compiles to native code)
And thanks for mentioning metalua, I had never heard of it! I know some lua but I'm far from being an expert, nor have I used it in anything larger than a few hundred lines.
I'm not the biggest fan of Common Lisp either, I too prefer the Scheme side of things though I don't think we haven't reached the golden standard yet (in my mind it would be a Clojure-like functional Lisp with first class support for actors, that compiles to native code)
That mutability is what Firefox XUL offered to extensions for many years, and when it was taken away there were — and still are — cries of outrage from devoted extensions users who expected to be able to modify anything.
So the model has lots of downsides, but certainly it’s not a dealbreaker.
So the model has lots of downsides, but certainly it’s not a dealbreaker.
This is the reason why I love it. Yes, it's not pretty, but you can hack anything into it really quickly. The fact that it's so 'informal' is the reason why it works so well imo.
How does this compare to Sublime? I ask because that's my simple/fast editor of choice currently.
In my own experience, it's just as fast if not a tiny bit faster, but what it's _really_ good at is customisability. With sublime I tried once to write a small plugin for gofmt and go vet (I don't remember what was wrong with the existent ones), and I gave up because it was more complex than I anticipated. With Lite XL I did it in 10 minutes and about 20 lines of lua code (though I did use this other plugin, it's a kind of support for linters).
Whatever I wanted to do it felt like I can just open the config and hack on it. Sublime never felt this way.
Whatever I wanted to do it felt like I can just open the config and hack on it. Sublime never felt this way.
I love sublime. I daily Vscode for the remote ssh integration but I always have subl open for scratch padding, notes, opening huge files etc. It’s so fast.
I like it, very fast, but it has some issue with idle CPU usage on my M1. It stays at 70% on idle whereas sublime at 0.0% when not used, opening the same project.
Looks like it's a known issue: https://github.com/lite-xl/lite-xl/issues/1237
Maybe try 2.2 when it comes out?
Maybe try 2.2 when it comes out?
Are there any text editors that have MDI? I know TDI is really popular, but I prefer the classic windows 3.0 way of embedded document interfaces.
Me too. However it seems that all editors moved to TDI around the turn of the century. Sam is a graphical text editor that still maintains the MDI interface, but it is too bare bones for my taste.
Well, if you are looking at windows, there is Akelpad and just testing it and it works. https://akelpad.sourceforge.net/en/index.php
Found it via: https://en.wikipedia.org/wiki/Comparison_of_text_editors
Also, I just noticed that VSC++ Express 2008 has MDI as well under options.
Found it via: https://en.wikipedia.org/wiki/Comparison_of_text_editors
Also, I just noticed that VSC++ Express 2008 has MDI as well under options.
I suppose the only featured application which still uses MDI are smalltalk derivatives like Squeak. I'll have to play with that to make sure it can access the file system external to the vm.
I was just trying this today. Unfortunately, it's lsp plugin isn't in an acceptable enough state for my tastes yet.
Also it's doesn't open a proper open file dialog.
Lapce (which also isn't yet to ready to replace vscode for me yet) seems to be more complete at this point.
Also it's doesn't open a proper open file dialog.
Lapce (which also isn't yet to ready to replace vscode for me yet) seems to be more complete at this point.
GUI based, not terminal based. In case you were curious as I was.
Thought this was gonna be GNU Zile: https://www.gnu.org/software/zile/
My first attempts at using Lua did not work very well. Until I tried to use it as an embedded scripting language, and suddenly it clicked. Shocker, I know. ;-) But I had never tried anything like that before, and it was eye opening. And in that function, Lua is beautiful, both as seen from the C-side and as seen from the user's side when scripting the application.
So this makes sense intuitively. It's what these languages were made for. C for parts that are performance critical or need to interface with the OS, Lua to orchestrate it all.
I would love an editor that was basically GNU Emacs, but with Lua instead of elisp. The zile project[0] aims to do something in a similar spirit, but I don't think they have many contributors. And realistically speaking, Emacs is something like 250,000 lines of lisp code, recreating all that in Lua would take a long time.
[0] https://www.gnu.org/software/zile/
So this makes sense intuitively. It's what these languages were made for. C for parts that are performance critical or need to interface with the OS, Lua to orchestrate it all.
I would love an editor that was basically GNU Emacs, but with Lua instead of elisp. The zile project[0] aims to do something in a similar spirit, but I don't think they have many contributors. And realistically speaking, Emacs is something like 250,000 lines of lisp code, recreating all that in Lua would take a long time.
[0] https://www.gnu.org/software/zile/
I use this on an ancient Chromebook because VSCode and Lapce feel sluggish in comparison. What it really needs is a plugin manager.
We actually do have one, about to be released: https://github.com/adamharrison/lite-xl-plugin-manager
Comes with a plugin to provide a gui in lite-xl. Once this gets to 1.0, we'll probably start bundling it with the `addons` release.
Comes with a plugin to provide a gui in lite-xl. Once this gets to 1.0, we'll probably start bundling it with the `addons` release.
I hope LPM gets to 1.0 soon. Having to download a lua file or clone a repository to plugins directory is easy, but it can get messy overtime. Also, I hope Lite XL has a plugin store/market like Sublime's packagecontrol.io or open-vsx.org. I think the current lite-xl-plugins repository is just too basic.
Can someone suggest an editor for macOS with smart text algorithms to allow work on unlimited file size or line length? I need to view unlimited text, switch between encodings (including hex) and I want editor with proper algorithms, so it'll work instantly and without loading entire file in the memory. Should support search with fast regex engine.
Editing would be nice too. I imagine editing as a sequence of actions that editor remembers and can undo/redo (including search/replace) and saving is actually applying that sequence of actions to the original file in some smart way.
Also I want it to start instantly, so I can use it as my general text file editor.
Colours, autocompletions and other nonsense is strictly not needed. Just black text on white background.
All those editors just die when I'm trying to edit a simple file of several hundreds GBs with lines of several GBs.
Editing would be nice too. I imagine editing as a sequence of actions that editor remembers and can undo/redo (including search/replace) and saving is actually applying that sequence of actions to the original file in some smart way.
Also I want it to start instantly, so I can use it as my general text file editor.
Colours, autocompletions and other nonsense is strictly not needed. Just black text on white background.
All those editors just die when I'm trying to edit a simple file of several hundreds GBs with lines of several GBs.
I would suggest to post your question as a „ask hn“. More people would see your questions this way
I would like that too. I'm sure lots of posters will have excellent suggestions.
There's been a lot of Ask HN's recently. It'd be nice to have fewer.
UltraEdit
> UltraEdit's file handling is designed to prevent it from using all the available memory, which would stop other applications from running. What does this mean to you? UltraEdit has no real limit on file size - and can easily open, edit, and save large text files in excess of 4 GB!
https://www.ultraedit.com/support/tutorials-power-tips/ultra...
> UltraEdit's file handling is designed to prevent it from using all the available memory, which would stop other applications from running. What does this mean to you? UltraEdit has no real limit on file size - and can easily open, edit, and save large text files in excess of 4 GB!
https://www.ultraedit.com/support/tutorials-power-tips/ultra...
Epsilon
https://www.lugaru.com/
Comes sufficiently close to be worth testing the free trial.
I don't know the file size limit, but it handles multi-GB files.
Does not fulfil the hex requirement. Recognizes and edits binary files but is not a hex editor. The previously suggested https://hexfiend.com/ looks better for that.
Unlimited line length, and can either horizontally scroll long lines or wrap them for display purposes.
Fast regex.
Unlimited undo/redo, including search/replace.
Comes sufficiently close to be worth testing the free trial.
I don't know the file size limit, but it handles multi-GB files.
Does not fulfil the hex requirement. Recognizes and edits binary files but is not a hex editor. The previously suggested https://hexfiend.com/ looks better for that.
Unlimited line length, and can either horizontally scroll long lines or wrap them for display purposes.
Fast regex.
Unlimited undo/redo, including search/replace.
HexFiend (https://hexfiend.com/) works well for files of enormous size but is only a hex editor.
It has been so long since I last used an editor that could handle very large files or long lines, that I'm struggling to remember one. Maybe SlickEdit? The Forte Agent newsreader?
The Scintilla editor widget is the cross-platform core of several good code editors, but I don't think it qualifies in this area.
I hope someone chimes in with an answer on any OS.
The Scintilla editor widget is the cross-platform core of several good code editors, but I don't think it qualifies in this area.
I hope someone chimes in with an answer on any OS.
You want BBEdit
I just opened 1.5GB binary file and it ate 2.5GB RAM according to Activity Monitor.
I tried to open 20GB single line text file and it started to eat RAM. I killed it at 60GB as I only have 64GB RAM.
So at least modern version does not seem to work well with big files.
vim does not seem to work either.
I tried to open 20GB single line text file and it started to eat RAM. I killed it at 60GB as I only have 64GB RAM.
So at least modern version does not seem to work well with big files.
vim does not seem to work either.
Ken is correct. IIRC, the very first version of BBEdit back in 1991(?) could handle files significantly larger than memory (on a system without memory mapping, no less).
I'd also love something that works in this situation. I've been contemplating writing something that does this for a while now but it would take a fair bit of work for the fringe cases where I'd actually need it, so it hasnt been written yet :(
Does vi maybe help in this case?
I‘d use vim. It’s already preinstalled. For this usecase you should also consider the various command line utilities like sed, awk, grep
An ambitious FOSS project like a plugin-rich text editor is always commendable, but - I could not understand from the FAQ what the motivation for this editor was. I mean, which itch does it scratch? Which deficiency in existing editors does it resolve?
I think the original lite scratched the itch of just being very, very simple.
This is a bit less simple, but still decidedly more so than many other editors.
It has very few dependencies, statically builds, and is just generally pretty extensible, whilst also being not an embedded web browser.
What drew me to it was just the ease of creating new functionality. When I found it, it didn't have any perl syntax highlighting, so I looked into how to add that.
It took me literally five minutes to get basic highlighting working. I'm not joking, with no previous exposure to the editor, and having not touched lua in years. After I had finished, I just kinda sat there, and went: "Huh.".
I looked over the editor, and pretty much got the gist of it in a single day. I can't say that's ever happened before to me for something so feature-filled. I've tried to add plugins to other non-browser editors (like Code::Blocks, or Padre), and it was always a complete shitshow, and incredibly time-consuming and confusing (I still have trouble compiling Code::Blocks on my system, due to a huge esoteric error dump that popped at one point, and is proving frustratingly difficult to resolve). Lite just kinda worked out of the box with no real resistance. I really liked that about it.
This is a bit less simple, but still decidedly more so than many other editors.
It has very few dependencies, statically builds, and is just generally pretty extensible, whilst also being not an embedded web browser.
What drew me to it was just the ease of creating new functionality. When I found it, it didn't have any perl syntax highlighting, so I looked into how to add that.
It took me literally five minutes to get basic highlighting working. I'm not joking, with no previous exposure to the editor, and having not touched lua in years. After I had finished, I just kinda sat there, and went: "Huh.".
I looked over the editor, and pretty much got the gist of it in a single day. I can't say that's ever happened before to me for something so feature-filled. I've tried to add plugins to other non-browser editors (like Code::Blocks, or Padre), and it was always a complete shitshow, and incredibly time-consuming and confusing (I still have trouble compiling Code::Blocks on my system, due to a huge esoteric error dump that popped at one point, and is proving frustratingly difficult to resolve). Lite just kinda worked out of the box with no real resistance. I really liked that about it.
for Windows, Linux and Mac OS
Derivative of lite editor
Plugins
Lightweight:
We are currently around 3MB in size and takes about 10MB in RAM (can be lower). The whole thing is just Lua running on a rendering engine.
Derivative of lite editor
Plugins
Lightweight:
We are currently around 3MB in size and takes about 10MB in RAM (can be lower). The whole thing is just Lua running on a rendering engine.
> What does lightweight mean?
It would traditionally mean a program running as little code as possible (dependencies included) for a given task, instead of relying on piles of pre-made libraries and frameworks, which obviously creep way more features than required.
However in this day and age, lightweight usually means it's not based on a web engine, although quite often it could still be huge and needlessly complex.
edit - post was edited in the meantime
It would traditionally mean a program running as little code as possible (dependencies included) for a given task, instead of relying on piles of pre-made libraries and frameworks, which obviously creep way more features than required.
However in this day and age, lightweight usually means it's not based on a web engine, although quite often it could still be huge and needlessly complex.
edit - post was edited in the meantime
For an Exhaustive list of editors point your browsers to:
https://www.texteditors.org/
https://www.texteditors.org/
That "exhaustive" list doesn't include Helix[1], an editor with more than 400 contributors and 17k GitHub stars, which has been in development for close to three years, and which is probably more widely used already than 95% of the editors on that list ever were.
[1] https://github.com/helix-editor/helix
[1] https://github.com/helix-editor/helix
It is a wiki, so now it does.
Doesn't seem that light to me. Notepad++ using 15 Megabytes of RAM, and 2 billion CPU cycles just to load and display on my screen.
"Lite"XL using 21 Megabytes of RAM, and 4 billion CPU cycles to load and display on my screen
"Lite"XL using 21 Megabytes of RAM, and 4 billion CPU cycles to load and display on my screen
What GUI Library does the editor use?
Last time I looked it was simple software rendering on an SDL windows.
As simple as it goes. I was impressed by how fast it was given that software rendering should be quite slow, but these days CPU are so powerful that this might not be a problem
A simple OpenGL renderer could be added with minimal efforts I think.
As simple as it goes. I was impressed by how fast it was given that software rendering should be quite slow, but these days CPU are so powerful that this might not be a problem
A simple OpenGL renderer could be added with minimal efforts I think.
It's a bit more complicated to add the OpenGL renderer, because of subpixel font rendering. You need to sample the framebuffer to do it correctly in all cases, as well as a custom shader. It's on the list of things to do, but as you say, CPUs are generally powerful enough these days; so it's not super high-priority at the moment.
In most cases you should know the background color behind the text without sampling the buffer, or at least get an approximation or revert to grayscale AA when layering text on top of unknown background, but yeah I get the idea and it is an interesting trade off.
Software rendering for a text editor hasn't been a major bottleneck for a few decades, and while resolution has increased CPU speed has outpaced it.
But if OpenGL was used, wouldn't that have to go through Zink and MoltenVK for Apple? Or is there a Zink-like OpenGL wrapper for Metal?
SDL will let you push geometry directly without needing OpenGL now with its geometry API, and I think all of its drawing functions use that by default now. I don't know if that's adequate compared to OpenGL but it isn't entirely CPU bound. Dear ImGUI's SDL renderer uses it.
https://github.com/rxi/microui
the editor is a fork of: https://github.com/rxi/lite
the editor is a fork of: https://github.com/rxi/lite
A quick look at the source seems to indicate SDL and freetype.
Interesting discussion of rendering from one of related projects at https://rxi.github.io/cached_software_rendering.html
[deleted]
Looks extremely promising, cross-platform.
Can this thing even word wrap? Last time I checked out Lite or some variation it couldn't even word wrap.
Yes; F10 enables word wrap. It's a plugin included in the core.
Thanks a lot!
Edit: just tried it, it works. But unfortunately it only wraps on character, so it won't work for me now. As a writer I was looking for something more lightweight than VS code, and Lite XL looks promising. I'll keep an eye on it.
Edit: just tried it, it works. But unfortunately it only wraps on character, so it won't work for me now. As a writer I was looking for something more lightweight than VS code, and Lite XL looks promising. I'll keep an eye on it.
This is configurable. I use it in my android fork that I use for creative writing, `write-xl` (in case you're interested, here: https://github.com/adamharrison/write-xl ; not really ready for public consumption). You can set the word wrapping configuration via your user plugin by doing:
config.plugins.linewrapping.mode = "word"
The full list of options is here: https://github.com/lite-xl/lite-xl/blob/master/data/plugins/...
config.plugins.linewrapping.mode = "word"
The full list of options is here: https://github.com/lite-xl/lite-xl/blob/master/data/plugins/...
Thanks so much! FWIW, I actually tried looking for how to do that but couldn't find it. It's cool that there are so many knowledgeable people here :D
If you want a bit better discoverability; you may want to try the `addons` release; it comes with a settings plugin that lays out all the settings in GUI so you don't have to go through digging through the source. Could be helpful if you just wanna poke around.
So this is like a competitor to Notepad++ or more of a Sublime text competitor?
Sublime.
They have packages for pretty much every platform except Debian.
Debian takes forever when it comes to adding new packages. I'm talking years.
That doesn't prevent you from having a build path to create a .deb compatible with stable and making it available. In fact, that's a good way to improve your chances of getting into Debian proper.
If anyone's interested, I do have a `.deb` build here; but it's not an official one: https://github.com/adamharrison/lite-xl-simplified/releases/...
And I haven't tested it super hard, and it's only the 64-bit build.
And I haven't tested it super hard, and it's only the 64-bit build.
What does "enhanced" and "all-in-one" mean there?
"enhanced" is my branch that has a few experimental patches, a C rewrite of the tokenizer from lua; but I'd avoid it for now, as it can be slightly unstable.
"all-in-one" is my build that bundles all necessary files into the executable, so ships a completely portable, mostly statically built lite-xl as a single file.
"all-in-one" is my build that bundles all necessary files into the executable, so ships a completely portable, mostly statically built lite-xl as a single file.
Try AppImage binary.
Is it more lightweight than neovim and vim?
Why this over neovim I don’t get it
Any editor no matter how "light" you call it will be too fat cause this exists:
"vim" depends on
lib (3) gettext libiconv ncurses
build (1) clang-14
"vim" depends on
lib (3) gettext libiconv ncurses
build (1) clang-14
I would imagine ed has even fewer dependencies, ergo it is not lightweight. (Not that it is anyway, really)
There are smaller C compilers than clang.
Sublime Text is now getting squeezed from "above" (by VSCode) and from "below" (by Lite XL), while also having serious competition from TUI editors like Helix which are rapidly approaching it in features and performance. I'm not sure how Sublime can hope to survive long term against all of those, considering that Sublime's development pace appears to be by far the slowest of the bunch.