Get the top HN stories in your inbox every day.
p-e-w
maegul
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.
the_onion_hater
The main pain point of Sublime has always been it's extensibility, or lack thereof. The program is very rigid, and the plugins can't do much.
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
maegul
So I think the ColorHelper plug-in[1] is a better example of the modern gui hack in sublime. Basically goes all in on the HTML engine (for popup windows) that ships with sublime. I haven’t used it myself (HTML), but as far as I understand, buttons can effectively have callback functionality through “links” to commands. Or something like that.
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.
giancarlostoro
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.
undefined
xmcqdpt2
People grow very attached to their editors. I had a professor in university who paid 100$ every year for his subscription to
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.
kerneis
Slight tangent: it looks like Crisp is also available on Linux, according to their website.
ac130kz
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.
giancarlostoro
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.
rd07
After reading your comment, I tried to setup a CudaText + LSP Plugin + Intelephense as I mainly develop in PHP. Unfortunately, my experience of LSP on CudaText is not as good as Lite XL.
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.
chii
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
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
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
synergy20
geany works well too
dataflow
You might also like SciTE.
WalterBright
Here's another one with a very small footprint:
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
Med appears to be a command line text editor, while this is a gui text editor... different beasts entirely.
nine_k
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.
WalterBright
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
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
'med' stands for 'Micro Emacs in D'. You're living the toolmakers' dream Walter, thanks for the link.
Daunk
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.
aethy
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.
properparity
Also been thinking this.
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.
aethy
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.
alwillis
Certainly Vim has all of the Makefile machinery built-in and it wouldn't take much to customize it [1].
proxysna
Sounds like all you need is à plugin to call makefile targets from vim.
Daunk
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.
hiccuphippo
I haven't used it but there is :make which works with a Makefile.
nequo
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.
marssaxman
I built something which scratches that basic itch, though my taste differs from yours:
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
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++.
stephc_int13
"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.
alwillis
> 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.
mhd
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
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
(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
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.
mhd
Visually it's not that different, of course, but I don't see a more unified interface in the terminal these days. The Amiga might have had it, with its TRIPOS arg parsing, and of course you got your language-integrated text UIs like Oberon.
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.
Octoth0rpe
> 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)
sendfoods
There's now libui-ng [1] which seems to be active and already has many wrappers
eikenberry
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.
kristopolous
Fast native running binaries will never be anachronistic
eikenberry
I'm not saying they won't still be around. They will just use lower level graphics libraries and be more free form. The days of the 'native' GUI widgets are over.
mikro2nd
"cross platform graphics stacks make a lot more sense"
Oh how they laughed when Sun tried this with Java some 25 years ago...
einpoklum
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".
djur
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
You might want to check the helix editor. It has LSP support out of the box.
bbkane
https://github.com/lapce/lapce is not stable but already looks impressive.
xrayarx
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
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.
aethy
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.
jinwoo68
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
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."
altairprime
That mutability is what Firefox XUL offered to extensions for many years, and when it was taken away there were — and still are — cries of outrage from devoted extensions users who expected to be able to modify anything.
So the model has lots of downsides, but certainly it’s not a dealbreaker.
unsafecast
This is the reason why I love it. Yes, it's not pretty, but you can hack anything into it really quickly. The fact that it's so 'informal' is the reason why it works so well imo.
the__alchemist
How does this compare to Sublime? I ask because that's my simple/fast editor of choice currently.
unsafecast
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.
whalesalad
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.
lexoj
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
Looks like it's a known issue: https://github.com/lite-xl/lite-xl/issues/1237
Maybe try 2.2 when it comes out?
Yasuraka
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
Yup, word wrap is now a configurable core plugin. There's still a few minor issues with it, but it mostly works as expected.
guessbest
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
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
Well, if you are looking at windows, there is Akelpad and just testing it and it works. https://akelpad.sourceforge.net/en/index.php
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.
guessbest
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.
Get the top HN stories in your inbox every day.
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.