12 ms·

Lite XL: A lightweight text editor written in C and Lua

326 points by firstSpeaker 4y ago

eikenberry 4y ago
GUI based, not terminal based. In case you were curious as I was.
deleted 4y ago
[deleted]
xrayarx 4y ago
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.
- rahen 4y ago
  > 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
  - d3nj4l 4y ago
    How was the post edited in 10 minutes?
  - xrayarx 4y ago
    Sorry for the edit. I found their definition of lightweight and added that
kstenerud 4y ago
They have packages for pretty much every platform except Debian.
- snshn 4y ago
  Debian takes forever when it comes to adding new packages. I'm talking years.
  - dsr_ 4y ago
    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.
    - aethy 4y ago
      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/tag/v2.1 https://github.com/adamharrison/lite-xl-simplified/releases/... And I haven't tested it super hard, and it's only the 64-bit build.
      - einpoklum 4y ago
        What does "enhanced" and "all-in-one" mean there?
        aethy 4y ago
        "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.
- app4soft 4y ago
  Try AppImage binary.
xrayarx 4y ago
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
- bogwog 4y ago
  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.
  - jinwoo68 4y ago
    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.
    - sph 4y ago
      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."
anarchy89 4y ago
Is it more lightweight than neovim and vim?
snshn 4y ago
Looks extremely promising, cross-platform.
symisc_devel 4y ago
What GUI Library does the editor use?
- kuon 4y ago
  A quick look at the source seems to indicate SDL and freetype.
- stephc_int13 4y ago
  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.
  - tmtvl 4y ago
    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?
    - krapp 4y ago
      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.
  - aethy 4y ago
    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.
    - stephc_int13 4y ago
WalterBright 4y ago
Here's another one with a very small footprint: https://github.com/DigitalMars/med 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.
- kennywinker 4y ago
  Med appears to be a command line text editor, while this is a gui text editor... different beasts entirely.
  - nine_k 4y ago
    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 https://linux.die.net/man/1/ed
  - WalterBright 4y ago
    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.
    - eikenberry 4y ago
      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.
- JonChesterfield 4y ago
  'med' stands for 'Micro Emacs in D'. You're living the toolmakers' dream Walter, thanks for the link.
iza 4y ago
I use this on an ancient Chromebook because VSCode and Lapce feel sluggish in comparison. What it really needs is a plugin manager.
- aethy 4y ago
  We actually do have one, about to be released: https://github.com/adamharrison/lite-xl-plugin-manager 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.
  - rd07 4y ago
    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.
Yasuraka 4y ago
I stopped using lite-xl a few months back over the lack of word wrapping, but it looks like it's in as of October/v2.1.0 It's a good stopgap between vim and vscode
- aethy 4y ago
  Yup, word wrap is now a configurable core plugin. There's still a few minor issues with it, but it mostly works as expected.
djur 4y ago
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.
- dadoomer 4y ago
  You might want to check the helix editor. It has LSP support out of the box.
- bbkane 4y ago
  https://github.com/lapce/lapce https://github.com/lapce/lapce is not stable but already looks impressive.
lexoj 4y ago
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.
- Octoth0rpe 4y ago
  Looks like it's a known issue: https://github.com/lite-xl/lite-xl/issues/1237 https://github.com/lite-xl/lite-xl/issues/1237 Maybe try 2.2 when it comes out?
- aethy 4y ago
  Yeah; unfortunately, none of the core dev teams work on Macs, so while being known, it's hard to fix on our end. We'll get it eventually.
  - lexoj 4y ago
    Thank you for fixing it so quickly!
tmtvl 4y ago
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++.
- mhd 4y ago
  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.
  - tmtvl 4y ago
    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.
    - mikro2nd 4y ago
      (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.
  - eikenberry 4y ago
    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.
vbezhenar 4y ago
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.
- xrayarx 4y ago
  I‘d use vim. It’s already preinstalled. For this usecase you should also consider the various command line utilities like sed, awk, grep
- xrayarx 4y ago
  I would suggest to post your question as a „ask hn“. More people would see your questions this way
  - generalizations 4y ago
    There's been a lot of Ask HN's recently. It'd be nice to have fewer.
  - spicybright 4y ago
    I would like that too. I'm sure lots of posters will have excellent suggestions.
- globalnode 4y ago
  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 :(
Daunk 4y ago
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.
- proxysna 4y ago
  Sounds like all you need is à plugin to call makefile targets from vim.
  - Daunk 4y ago
    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.
    - nequo 4y ago
      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.
      - engfan 4y ago
        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.
vouaobrasil 4y ago
Can this thing even word wrap? Last time I checked out Lite or some variation it couldn't even word wrap.
- aethy 4y ago
  Yes; F10 enables word wrap. It's a plugin included in the core.
  - vouaobrasil 4y ago
    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.
    - aethy 4y ago
      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 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/linewrapping.lua#L13-L25 https://github.com/lite-xl/lite-xl/blob/master/data/plugins/...
      - vouaobrasil 4y ago
        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
        aethy 4y ago
        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.
the__alchemist 4y ago
How does this compare to Sublime? I ask because that's my simple/fast editor of choice currently.
- whalesalad 4y ago
  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.
- unsafecast 4y ago
  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.
bobajeff 4y ago
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.
bitwize 4y ago
Thought this was gonna be GNU Zile: https://www.gnu.org/software/zile/ https://www.gnu.org/software/zile/
einpoklum 4y ago
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?
- aethy 4y ago
  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.
guessbest 4y ago
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.
- coliveira 4y ago
  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.
  - guessbest 4y ago
    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.
  - guessbest 4y ago
    Well, if you are looking at windows, there is Akelpad and just testing it and it works. https://akelpad.sourceforge.net/en/index.php https://akelpad.sourceforge.net/en/index.php Found it via: https://en.wikipedia.org/wiki/Comparison_of_text_editors https://en.wikipedia.org/wiki/Comparison_of_text_editors Also, I just noticed that VSC++ Express 2008 has MDI as well under options.
g8oz 4y ago
TextAdept is another lightweight editor written in C and extensible with Lua. Mature, cross platform and speedy.
- fithisux 4y ago
  Good you mentioned this fantastic editor.
ac130kz 4y ago
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.
- chii 4y ago
  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.
  - benatkin 4y ago
    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.
    - aniforprez 4y ago
      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
      - master-12 4y ago
        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 https://news.ycombinator.com/item?id=32657709
djha-skin 4y ago
So this is like a competitor to Notepad++ or more of a Sublime text competitor?
- unsafecast 4y ago
  Sublime.
p-e-w 4y ago
Lite XL is a small miracle. I can only echo other comments calling it an "open source Sublime Text". It is at least as responsive as Sublime in my tests, and feels even more lightweight. The executable is only 385 kilobytes on Linux, with just a handful of extremely basic system dependencies (SDL, Lua, FreeType, PCRE). 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.
- maegul 4y ago
  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.
  - deleted 4y ago
    [deleted]
  - giancarlostoro 4y ago
    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.
xrayarx 4y ago
For an Exhaustive list of editors point your browsers to: https://www.texteditors.org/ https://www.texteditors.org/
- p-e-w 4y ago
  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 https://github.com/helix-editor/helix
  - hiccuphippo 4y ago
    It is a wiki, so now it does.
bdrum 4y ago
Do you know why so many tiny text editors are exists? Thats because of gang of four book that based on text editor example...
- mcluck 4y ago
  Or maybe people just like to improve on the tools that they use every single day?
mrtweetyhack 4y ago
[dead]
gloosx 4y ago
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
- JonChesterfield 4y ago
  There are smaller C compilers than clang.
- xcdzvyn 4y ago
  I would imagine ed has even fewer dependencies, ergo it is not lightweight. (Not that it is anyway, really)
MrMan 4y ago
Why this over neovim I don’t get it
JonChesterfield 4y ago
Interesting discussion of rendering from one of related projects at https://rxi.github.io/cached_software_rendering.html https://rxi.github.io/cached_software_rendering.html
krylon 4y ago
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/ https://www.gnu.org/software/zile/
Jamie9912 4y ago
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

326 points by firstSpeaker 4y ago

eikenberry 4y ago

GUI based, not terminal based. In case you were curious as I was.

deleted 4y ago

[deleted]

xrayarx 4y ago

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.

rahen 4y ago
> 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
- d3nj4l 4y ago
  How was the post edited in 10 minutes?
- xrayarx 4y ago
  Sorry for the edit. I found their definition of lightweight and added that

kstenerud 4y ago

They have packages for pretty much every platform except Debian.

snshn 4y ago
Debian takes forever when it comes to adding new packages. I'm talking years.
- dsr_ 4y ago
  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.
  - aethy 4y ago
    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/tag/v2.1 https://github.com/adamharrison/lite-xl-simplified/releases/... And I haven't tested it super hard, and it's only the 64-bit build.
    - einpoklum 4y ago
      What does "enhanced" and "all-in-one" mean there?
      - aethy 4y ago
        "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.
app4soft 4y ago
Try AppImage binary.

xrayarx 4y ago

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

bogwog 4y ago
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.
- jinwoo68 4y ago
  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.
  - sph 4y ago
    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."

anarchy89 4y ago

Is it more lightweight than neovim and vim?

snshn 4y ago

Looks extremely promising, cross-platform.

symisc_devel 4y ago

What GUI Library does the editor use?

kuon 4y ago
A quick look at the source seems to indicate SDL and freetype.
stephc_int13 4y ago
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.
- tmtvl 4y ago
  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?
  - krapp 4y ago
    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.
- aethy 4y ago
  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.
  - stephc_int13 4y ago

WalterBright 4y ago

Here's another one with a very small footprint: https://github.com/DigitalMars/med 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.

kennywinker 4y ago
Med appears to be a command line text editor, while this is a gui text editor... different beasts entirely.
- nine_k 4y ago
  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 https://linux.die.net/man/1/ed
- WalterBright 4y ago
  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.
  - eikenberry 4y ago
    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.
JonChesterfield 4y ago
'med' stands for 'Micro Emacs in D'. You're living the toolmakers' dream Walter, thanks for the link.

iza 4y ago

I use this on an ancient Chromebook because VSCode and Lapce feel sluggish in comparison. What it really needs is a plugin manager.

aethy 4y ago
We actually do have one, about to be released: https://github.com/adamharrison/lite-xl-plugin-manager 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.
- rd07 4y ago
  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.

Yasuraka 4y ago

I stopped using lite-xl a few months back over the lack of word wrapping, but it looks like it's in as of October/v2.1.0 It's a good stopgap between vim and vscode

aethy 4y ago
Yup, word wrap is now a configurable core plugin. There's still a few minor issues with it, but it mostly works as expected.

djur 4y ago

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.

dadoomer 4y ago
You might want to check the helix editor. It has LSP support out of the box.
bbkane 4y ago
https://github.com/lapce/lapce https://github.com/lapce/lapce is not stable but already looks impressive.

lexoj 4y ago

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.

Octoth0rpe 4y ago
Looks like it's a known issue: https://github.com/lite-xl/lite-xl/issues/1237 https://github.com/lite-xl/lite-xl/issues/1237 Maybe try 2.2 when it comes out?
aethy 4y ago
Yeah; unfortunately, none of the core dev teams work on Macs, so while being known, it's hard to fix on our end. We'll get it eventually.
- lexoj 4y ago
  Thank you for fixing it so quickly!

tmtvl 4y ago

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

mhd 4y ago
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.
- tmtvl 4y ago
  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.
  - mikro2nd 4y ago
    (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.
- eikenberry 4y ago
  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.

vbezhenar 4y ago

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.

xrayarx 4y ago
I‘d use vim. It’s already preinstalled. For this usecase you should also consider the various command line utilities like sed, awk, grep
xrayarx 4y ago
I would suggest to post your question as a „ask hn“. More people would see your questions this way
- generalizations 4y ago
  There's been a lot of Ask HN's recently. It'd be nice to have fewer.
- spicybright 4y ago
  I would like that too. I'm sure lots of posters will have excellent suggestions.
globalnode 4y ago
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 :(

Daunk 4y ago

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.

proxysna 4y ago
Sounds like all you need is à plugin to call makefile targets from vim.
- Daunk 4y ago
  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.
  - nequo 4y ago
    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.
    - engfan 4y ago
      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.

vouaobrasil 4y ago

Can this thing even word wrap? Last time I checked out Lite or some variation it couldn't even word wrap.

aethy 4y ago
Yes; F10 enables word wrap. It's a plugin included in the core.
- vouaobrasil 4y ago
  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.
  - aethy 4y ago
    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 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/linewrapping.lua#L13-L25 https://github.com/lite-xl/lite-xl/blob/master/data/plugins/...
    - vouaobrasil 4y ago
      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
      - aethy 4y ago
        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.

the__alchemist 4y ago

How does this compare to Sublime? I ask because that's my simple/fast editor of choice currently.

whalesalad 4y ago
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.
unsafecast 4y ago
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.

bobajeff 4y ago

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.

bitwize 4y ago

Thought this was gonna be GNU Zile: https://www.gnu.org/software/zile/ https://www.gnu.org/software/zile/

einpoklum 4y ago

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?

aethy 4y ago
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.

guessbest 4y ago

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.

coliveira 4y ago
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.
- guessbest 4y ago
  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.
- guessbest 4y ago
  Well, if you are looking at windows, there is Akelpad and just testing it and it works. https://akelpad.sourceforge.net/en/index.php https://akelpad.sourceforge.net/en/index.php Found it via: https://en.wikipedia.org/wiki/Comparison_of_text_editors https://en.wikipedia.org/wiki/Comparison_of_text_editors Also, I just noticed that VSC++ Express 2008 has MDI as well under options.

g8oz 4y ago

TextAdept is another lightweight editor written in C and extensible with Lua. Mature, cross platform and speedy.

fithisux 4y ago
Good you mentioned this fantastic editor.

ac130kz 4y ago

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.

chii 4y ago
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.
- benatkin 4y ago
  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.
  - aniforprez 4y ago
    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
    - master-12 4y ago
      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 https://news.ycombinator.com/item?id=32657709

djha-skin 4y ago

So this is like a competitor to Notepad++ or more of a Sublime text competitor?

unsafecast 4y ago
Sublime.

p-e-w 4y ago

Lite XL is a small miracle. I can only echo other comments calling it an "open source Sublime Text". It is at least as responsive as Sublime in my tests, and feels even more lightweight. The executable is only 385 kilobytes on Linux, with just a handful of extremely basic system dependencies (SDL, Lua, FreeType, PCRE). 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.

maegul 4y ago
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.
- deleted 4y ago
  [deleted]
- giancarlostoro 4y ago
  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.

xrayarx 4y ago

For an Exhaustive list of editors point your browsers to: https://www.texteditors.org/ https://www.texteditors.org/

p-e-w 4y ago
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 https://github.com/helix-editor/helix
- hiccuphippo 4y ago
  It is a wiki, so now it does.

bdrum 4y ago

Do you know why so many tiny text editors are exists? Thats because of gang of four book that based on text editor example...

mcluck 4y ago
Or maybe people just like to improve on the tools that they use every single day?

mrtweetyhack 4y ago

[dead]

gloosx 4y ago

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

JonChesterfield 4y ago
There are smaller C compilers than clang.
xcdzvyn 4y ago
I would imagine ed has even fewer dependencies, ergo it is not lightweight. (Not that it is anyway, really)

MrMan 4y ago

Why this over neovim I don’t get it

JonChesterfield 4y ago

Interesting discussion of rendering from one of related projects at https://rxi.github.io/cached_software_rendering.html https://rxi.github.io/cached_software_rendering.html

krylon 4y ago

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/ https://www.gnu.org/software/zile/

Jamie9912 4y ago

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