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.
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.
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.
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.
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'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 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.
- 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.
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 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.
> 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)
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.
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.
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.
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.
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.
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.
> 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!
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.
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.
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 :(
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.
[+] [-] p-e-w|3 years ago|reply
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|3 years ago|reply
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.
[+] [-] xmcqdpt2|3 years ago|reply
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.
[+] [-] ac130kz|3 years ago|reply
[+] [-] giancarlostoro|3 years ago|reply
https://cudatext.github.io/
[+] [-] chii|3 years ago|reply
[+] [-] dataflow|3 years ago|reply
[+] [-] WalterBright|3 years ago|reply
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|3 years ago|reply
[+] [-] JonChesterfield|3 years ago|reply
[+] [-] Daunk|3 years ago|reply
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.
[+] [-] aethy|3 years ago|reply
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.
[+] [-] properparity|3 years ago|reply
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.
[+] [-] alwillis|3 years ago|reply
[1]: https://vimways.org/2018/runtime-hackery/
[+] [-] proxysna|3 years ago|reply
[+] [-] marssaxman|3 years ago|reply
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).
[+] [-] tmtvl|3 years ago|reply
[+] [-] stephc_int13|3 years ago|reply
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.
[+] [-] mhd|3 years ago|reply
[+] [-] Octoth0rpe|3 years ago|reply
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)
[+] [-] eikenberry|3 years ago|reply
IE. IMO that ship has sailed and using lower level/cross platform graphics stacks make a lot more sense these days.
[+] [-] einpoklum|3 years ago|reply
[+] [-] djur|3 years ago|reply
[+] [-] xrayarx|3 years ago|reply
Plug-ins are not necessarily compatible
[+] [-] the__alchemist|3 years ago|reply
[+] [-] unsafecast|3 years ago|reply
Whatever I wanted to do it felt like I can just open the config and hack on it. Sublime never felt this way.
[+] [-] whalesalad|3 years ago|reply
[+] [-] lexoj|3 years ago|reply
[+] [-] Yasuraka|3 years ago|reply
It's a good stopgap between vim and vscode
[+] [-] aethy|3 years ago|reply
[+] [-] guessbest|3 years ago|reply
[+] [-] g8oz|3 years ago|reply
[+] [-] bobajeff|3 years ago|reply
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.
[+] [-] eikenberry|3 years ago|reply
[+] [-] bitwize|3 years ago|reply
[+] [-] krylon|3 years ago|reply
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/
[+] [-] iza|3 years ago|reply
[+] [-] vbezhenar|3 years ago|reply
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|3 years ago|reply
[+] [-] 323|3 years ago|reply
> 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...
[+] [-] HaroldPD|3 years ago|reply
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.
[+] [-] acdibble|3 years ago|reply
[+] [-] foresto|3 years ago|reply
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.
[+] [-] kenferry|3 years ago|reply
[+] [-] globalnode|3 years ago|reply
[+] [-] taf2|3 years ago|reply
[+] [-] xrayarx|3 years ago|reply
[+] [-] einpoklum|3 years ago|reply
[+] [-] aethy|3 years ago|reply
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.
[+] [-] xrayarx|3 years ago|reply
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.