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.

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.

Mainly when creating user interfaces, you can't have buttons (for example a "run" button), the only official UI components are the command palette where you search commands, and a "panel", which is basically a single separate text view.

Plugins such as the terminal plugin [1] uses this panel to show an interactive terminal, but anything you do, such as call another plugin, or simply search text, will remove your panel and replace it with another.

The only ways to create real UIs are with very ingenious workarounds, notable mentions being:

- The color picker plugin [2], which literally bundles a small native executable for each platform it runs, containing a color wheel, which the plugin will call, the user will select a color, and the program will close, returning the color code in its exit code, which the plugin is listening to.

- The debugger plugin [3] which has the most complex workaround I have seen using sublime's html capabilities. It uses the panel to show html elements, buttons with images, texts, lists, tabs, everything thorough this workaround. But again, try to search text and you loose it.

That's mainly where VSCode "won", although I still daily drive Sublime when I am not on a "full blown IDE".

[1]: https://github.com/randy3k/Terminus

[2]: https://github.com/weslly/ColorPicker

[3]: https://github.com/daveleroy/sublime_debugger

Which doesn’t seem too bad to be honest. The author of that plug-in has also written a markdown to HTML extension for the purposes of making it easier to use the HTML engine, and is what is used by the LSP ecosystem for popup windows.

But yea, honestly it’s a little strange to me that they don’t ship a basic GUI api that’s moderately flexible for things like buttons text and windows but uses their own GUI engine.

[1] https://packagecontrol.io/packages/ColorHelper

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.

https://crisp.com/

which he used for email and notes. He has a windows workstation set up with KVM (because the department is Linux based) solely so that he can use Crisp.

Sublime could easily survive another 30 years in some reduced capacity.

https://cudatext.github.io/

Also, looking at its repository, CudaText currently only has 1 active contributor, which is a little worrying if I want to use it as my main text editor. I hope the community around CudaText become bigger because I think the concept is good, and I really hope CudaText can be on par with Sublime Text.

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.

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

But the configuration of what marketplace is used and what extensions have access to the privileged "proposed API" makes huge difference in what Microsoft/GitHub can provide as user experience and what other developers can do.

See this great post for detailed explanation how Microsoft created a closed ecosystem around VS Code https://news.ycombinator.com/item?id=32657709

I'm perfectly aware of what Microsoft could do in some distant future. But as is, for all intents and purposes, VSCode is open source

... Except that if you use the source to make your own build, you lose the extension ecosystem that is one of VSC's major selling points. It is at best a worked example of tivoization.

    rm -fr ~/.vscode/*
    cp -a ~/.vscode-oss/* ~/.vscode/
    # Run VS Code, download extensions
    cp -a ~/.vscode/* ~/.vscode-oss/

I think there's also a hacky way to let VSCodium access the VS Code extension marketplace, but I believe it's an EULA violation.

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.

If you want a command-line text editor, try the classic ed [1] :-D This was a kind of editor you might have to use with a teletype that prints on paper.

[1]: https://linux.die.net/man/1/ed

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

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.

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.

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

[1]: https://vimways.org/2018/runtime-hackery/

It's also near impossible to get I J K L working as the cursor keys in VIM without having some major interference.

You could write elisp functions for your tasks and bind them to your prefered keys, with or without Evil.

With evil-mode, there's no excuse not to try it even if you find Vim's way of controlling input superior (which it as well may be).

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

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.

Mac users don't want all GUI apps to look alike; however, they should follow macOS UI/UX guidelines regarding copy/paste, drag and drop, keyboard conventions, etc. The whole point is to not have users having to relearn these basics for every new application.

Developers generally get these conventions "for free" by using the frameworks built-in to macOS. That doesn't prevent developers from creating custom, stylized interfaces if that's what's needed.

Even Apple's pro apps (Final Cut, Logic, etc.) look quite different from those that are bundled with macOS such as iMovie and Garageband.

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.

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.

But beyond that, it's a mirror of the graphical side. I mean, it's not like the GUI invented a lot of new widgets, either. There are still buttons and menus, it's just that they look and behave differently in each app. The same goes for the CLIs, where there's no rhyme or reason for all the long/short parameters, sub-commands etc.; To use the git metaphor, we're in a bathroom where all the porcelain is coming from different manufacturers and your got your brutalist toilet bowl next to your gold plated sink. And nobody knows what to do with the three shells.

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)

[1] https://libui-ng.github.io/libui-ng/

IE. IMO that ship has sailed and using lower level/cross platform graphics stacks make a lot more sense these days.

Native-ish interfaces are still pretty prevalent on mobile though.

Oh how they laughed when Sun tried this with Java some 25 years ago...

Plug-ins are not necessarily compatible

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.

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.

You can make a very customisable editor in a very flexible meta language like Lisp. If you do it in Lua, you have an absolute mess. I spent a few days studying Lite XL's source code before deciding the choice of language was going to be its downfall, unless they adopt very strict and well-documented interfaces.

I feel no one's trying to understand why Lisp was a thing and are doomed to try, and fail, to recreate Emacs in a subpar language. IMHO, neovim suffers from the same problem. Their choice of language is a very unstable foundation to build all those IDE-like features. vimscript is terrible, but was tailored for the problem at hand.

"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."

You don't have macros as far as I can tell, though meta lua looks suspiciously close to it.

What parts of lisp do you see missing from this?

I do not want to sound condescending, I just hope to convince you to try something new: have you used a Lisp language before? Just knowing the syntax doesn't count. People have talked about it much more and much better than I can do in a comment.

If you haven't, no worries. I recommend a weekend with Racket. Then we can disagree that Lua is a worse choice than Lisp, but at least we will agree that the latter is infinitely more flexible and malleable.

Yes, written a compiler in common lisp and various toys in scheme. Spent some of yesterday porting functions from SRFI-1 to Shutt's Kernel which is pretty close to a lisp. Interesting that you claimed first class macros, they're usually second class in lisps.

I like scheme because I'm far enough down the compilers rabbit hole that language syntax looks like obfuscation in the way of the SSA representation. Writing the syntax tree directly is attractive there.

I find macros pretty confusing. Common lisp has straightforward behaviour but needs a lot of ceremony to make them reliable. Scheme's hygienic rewrites look simple but I don't understand the machinery behind them. Lexically scoped fexpr have obvious behaviour and implementation hence the interest in Kernel.

Which is to say I'm not disputing the lisp ~= lua premise from a position of total ignorance. The semantics look pretty similar to me. Lua doesn't have control over syntax, in (reader) macro sense, so perhaps it's metalua I should be equating to scheme. As above I'm not very focused on syntax.

I also write a lot of lua so am keenly interested in the distinctions I'm missing in the above.

And thanks for mentioning metalua, I had never heard of it! I know some lua but I'm far from being an expert, nor have I used it in anything larger than a few hundred lines.

I'm not the biggest fan of Common Lisp either, I too prefer the Scheme side of things though I don't think we haven't reached the golden standard yet (in my mind it would be a Clojure-like functional Lisp with first class support for actors, that compiles to native code)

So the model has lots of downsides, but certainly it’s not a dealbreaker.

Whatever I wanted to do it felt like I can just open the config and hack on it. Sublime never felt this way.

Maybe try 2.2 when it comes out?

It's a good stopgap between vim and vscode

Found it via: https://en.wikipedia.org/wiki/Comparison_of_text_editors

Also, I just noticed that VSC++ Express 2008 has MDI as well under options.

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.

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/

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.

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!

https://www.ultraedit.com/support/tutorials-power-tips/ultra...

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.

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 tried to open 20GB single line text file and it started to eat RAM. I killed it at 60GB as I only have 64GB RAM.

So at least modern version does not seem to work well with big files.

vim does not seem to work either.

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.

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.

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

https://www.texteditors.org/

[1] https://github.com/helix-editor/helix

"Lite"XL using 21 Megabytes of RAM, and 4 billion CPU cycles to load and display on my screen

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.

the editor is a fork of: https://github.com/rxi/lite

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.

config.plugins.linewrapping.mode = "word"

The full list of options is here: https://github.com/lite-xl/lite-xl/blob/master/data/plugins/...

And I haven't tested it super hard, and it's only the 64-bit build.

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

"vim" depends on

lib (3) gettext libiconv ncurses

build (1) clang-14