aethy

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.

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.

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.

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.

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

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.

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

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.

Yes; F10 enables word wrap. It's a plugin included in the core.

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, multipurpose, etc.. and then leave the rest to a really robust plugin ecosystem that wasn't possible to the same degree under lite.

The UI is done using an immediate rendering model.

It is entirely composed of two rendering operations, drawing solid color rects, or rendering text from a true type font.

You can read a bit about the underlying technology here: https://rxi.github.io/cached_software_rendering.html

It's quite brilliant.

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.

rxi, lite's original author, considers lite to be complete, and isn't accepting new feature prs, which is fair enough.

lite-xl was forked to keep the same general principle of simplicity but going a bit further with features.

Yeah, there's a pre-release here: https://github.com/lite-xl/lite-xl/releases/tag/v2.1.0

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.

Fair enough; totally understand. If you ever can think of anything please don't hesitate to fire up an issue on the tracker. We're (very slowly) going through them.

That's what I mean. It never returns 0, so is thus always truthy if it finds something.

If you do `if (str.indexOf("a"))` in javascript; you'll miss out on the case where the string starts with "a", because the index returned 0, which is falsy.

EDIT: Oh, sorry, I see what you mean. You're right, my bad.

EDIT2: I guess, let me rephrase. 0 is rarely returned for things, so the falsiness of it doesn't usually enter into the equation. So you can do things like that, regardless of the truthiness of 0, because it's not used, whereas in other langauges, you usually have to check, unless they have 0 as truthy as well. (though I guess this isn't much of an argument in favour of 1-indexes)

Yeah; the indexing is weird when you're not used to it; but honestly I find starting arrays at 1 is actually incredibly useful for business logic. It's terrible for math, but it allows you to use things like truthiness really effectively for compound statements that return indices and stuff.

Like, for example, `string.find` returns the index where something's found. You can just do `if str:find("a")` if you want to test to see whether a string contains "a", whereas in most other languages that test for location you're required to check that the result isn't equal to `string::npos`, `null` (if your langauge supports that), `-1`, or some other value that's not 0. Lua, you can assume that it's truthy if it's found, because 1 is the start of the string, not 0.

Took me a while to get used to, but I really like the idiom now for things that just high-level string stuff, and glue code.

Hey; I'm part of the dev community over at lite-xl; what're your top asks? I can see if we can throw it into the feature queue (though the queue is already pretty long).

No; rxi wrote a rendering cache infront of the renderer. It doesn't require a widget library for this reason; it's able to efficiently implement an immediate renderer. Simplifies the codebase a lot.