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.
"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.
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.
- 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.
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:
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 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.
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.
If you're at all interested (though I'm not doing releases yet), I have a fork called 'write-xl' (https://github.com/adamharrison/write-xl), which does have a git plugin that autocommits+pushes to git on double save (double ctrl+s), as well as a bunch of other standard markdown creative writing stuff (bolding on ctrl+b, spellcheck, etc..) . I use it on my android tablet for creative writing, and have disabled a bunch of the more expensive computations to get a smoother experience.
Are you interested in releases for something like that?
Yes; people have built these before, so it's not really a problem with the source (I've even cross-compiled it for arm android); it's more just not part of the pipeline yet.
Given the prevalence of mac, this makes sense to support; but apple makes it really tricky to do things if you don't actually have mac hardware; even getting the x86_64 mac build built properly is a real struggle. So, we'll certainly try.
Yeah, lol. It's a balancing act. Ideally we give it just enough juice to allow for things like native plugins, and the easy expected core stuff like nice font rendering
, process management, multicursors, etc.. and then leave the rest to a really robust plugin ecosystem that wasn't possible to the same degree under lite.
It's unlikely that we would include that in core lite-xl due to size and complexity, but we aim to have an extremely robust plugin system (all current syntax definitions come from plugins).
It is totally possible to integrate an lpeg and scintilla plugin which could drop in replace the existing syntax support.
We already have a community member doing this, but with TreeSitter, though I'm not sure where that effort is at, at the moment.
There were some minor issues having the dev team get a working macbook that could test some stuff, to make sure there were no regressions. We're going through and closing PRs now, so hopefully should transition to a full release shortly.
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.