This editor claims to be lightweight, citing that it uses 30MB of RAM. But I assume that's without any extensions loaded.
Back in the day, though, one joke about Emacs was that it's an acronym for Eight Megabytes All Continuously Swapping. This was meant to highlight Emacs's reputation for bloat. Right now when I run Emacs it's using a lot more than 30, let alone eight. I'm pretty sure most of that is all the modes I have installed for every language I might ever use, regardless of whether I'm actually using it right now.
About 15 years back Visual Studio had a reputation for bloat, but my experience was that it was actually quite lightweight and snappy, especially compared to Eclipse and IntelliJ. Until you install ReSharper, which transformed it into 50 tons of molasses.
At work, Visual Studio Code currently consumes about 1GB of RAM and takes 5+ minutes to start up. On my personal computer, a 2013 MacBook, it uses more like 50MB and starts darn near instantaneously. But they're very different beasts; on my MacBook I've got it configured to only load the plugins I need for each project. At work we've got a whole dang Devcontainer that includes configuration to load I-don't-know-how-many extensions, basically anything anyone on the team has ever wanted. The devcontainer extension makes you put the list of extensions to load into a file that needs to be checked into source control. So the only way for someone to get this tool they want is to make everyone else get it, too. All to sling a relatively modest volume of Python code.
And of course if I try to opt out of all of that I make my life even harder. Trying to get by without that pile of crap is just spitting in the wind. Run-time requirements aren't documented; they're shoved into an undocumented and ever-growing list of Bash commands in the Dockerfile. Coding standards aren't documented or managed with something straightforward like Git hooks; they're enforced through a plugin and its configuration.
I do remember when vscode was lightweight. It happened to be a time when not many plugins were available. That put a hard limit on just how much bloat you could accomplish. But, of course, as soon as it got popular people started creating plugins for darn near everything.
Perhaps the problem isn't the editors. Perhaps it's us.
Installing multiple programs on my computer or a server is complicated, and slows things down, and it's insecure and hard to replicate. So we created VMs. And for a while VMs were great. But then we started putting everything we needed in the VMs, and they also became complicated, and slow, and insecure and whatnot. So we have containers. And containers are now slowly getting bloated too. Kubernetes simplified some things, but now we need Helm to deal with K8s, and Helm itself is now quite complicated.
Editors start lightweight and fast, then get bloated with features. So does productivity software. Programming languages start simple and easy to use and understand, and progressively get more features, each of which seems nice in isolation, but soon the codebases use everything, and it interacts, and you need decades of experience to use it all proficiently.
Same for libraries. For network protocols. For standards of all kinds.
This is exactly why I switched from containers to nix flakes and from Vs code to neovim or Helix. The difference is night and day. It's so nice to have my editor open instantly and to be able to have multiple instances open at once. The LSP is by far the most memory hungry. It's definitely worth the effort.
> On my personal computer, a 2013 MacBook, it uses more like 50 and starts darn near instantaneously.
Just for clarification, do you mean 50 GiB or 50 MiB? I'm assuming MiB in this scenario, since allocating 50 GiB doesn't mix with an instantaneous startup.
Yup, it is your works crazy policy of making sure everyone gets a one size fit all VS code Configuration. I’ve loaded VS code on a 10 year-old Lenovo and it runs just fine with only basic Python plug-ins. Five minute startup time is crazy.
> Perhaps the problem isn't the editors. Perhaps it's us.
For coming up on a decade I've used Vim with a minimal .vimrc and no plugins. The only time I deviate from this is when I am writing in an s-expression based language. I would probably deviate from this to write Java or C#, but I haven't written either in a while.
There are upsides and downsides. The biggest upside is simply that I haven't spent ANY time learning new editors or new editor features; I'll occasionally learn about a feature of Vim that I didn't know existed, but that's very oriented toward solving immediate problems, because it tends to happen when I run into something that feels like there's probably an easier way to do it, and I'll do a quick internet search. I think a lot of devs spend a lot of time learning tools with the sense that the time spent will be paid back by time savings from using the tools, but the reality is way more hit-and-miss, and I think a lot of people could benefit from being more selective in what they spend their learning time on.
The thing that Vim completely misses is being able to jump to the appropriate file where a class/function is defined. This is more of a tradeoff than IDE folks recognize: when I was using PyCharm/IntelliJ/ReSharper, I found that being able to jump around easily would hide the fact that my projects were growing in size and complexity. The tooling makes this less painful up front, but eventually, you still feel the pain, because eventually there's some bug that cascades through a bunch of files, and you still have to reason about all of them. Finding definitions isn't the core issue with having a lot of definitions, reasoning about how they interact is the core issue, and the IDE tooling doesn't solve that. Being in Vim and having to deal with my project's file structure directly and explicitly means I feel the pain of complexity earlier, when it's easier to fix.
If I'm being honest, I'm not sure that the tradeoffs comes out in Vim's favor here. I don't think we get to have a conclusive answer because there's simply nobody who uses both vanilla Vim and the best IDEs at a high enough level to have an informed opinion about which is better. I'd say I am close because I have used both extensively, but my IDE knowledge is outdated by about a decade.
But, I've said before and I'll say again that entering text into files isn't usually the limiting factor of software development speed. If I'm mentoring a new programmer I'd rather see them learn TDD and/or how to leverage type systems and write code in Notepad, than see them write untested, unchecked code in The Best IDE/Editor Ever. Of course, there's no reason to go to those extremes.
Your 3rd and last paragraphs reminded me of a feature I really like about F#: all source files in an assembly have an explicit, sequential compilation order. And you can only have references to things that had been defined earlier, either in the current file or in a file that comes earlier in the compilation order.
It makes learning and navigating a new codebase much easier. So much so that it doesn't really require IDE tooling the way it does with most mainstream languages. It's harder to get lost when you always know which way is up. Consciously thinking about whether you're doing top-down or bottom-up design also flows naturally from this, for the same reason, and that seems to encourage more thoughtful, readable code design.
Is it more work? Up-front, yes, absolutely. In the long run, though? By the time I finished my first year of CS education I had already been exposed to many many examples of cases where greedy algorithms consistently produce sub-optimal results. Perhaps they aren't teaching people about that in school anymore.
> I found that being able to jump around easily would hide the fact that my projects were growing in size and complexity.
That is a good point. Having IDE features like auto-import, jump to definition, etc., definitively allow for a more messy project structure.
Still, I always wonder how big projects people advocating "no IDE features" actually have worked on (or alternatively - if they are some sort of memory savants). One thing is a small-medium sized personal project. Another is a 10-20 man cooperation where you have only written a portion of the code, and a big chunk of that is a long time since you written. IMO that require lots of code reading, which is very painful without jump to definition... I don't really see how a perfect project organization could sufficiently remove that reading friction.
Writing extensions in Lua is huge. (Same as OBS) Looks very simple and productive.
It's one of the main reasons I've stuck to Sublime... extending with Python is very easy and works everywhere.
Even if both Zed and VSCode are strong in other areas.. Rust extensions makes me cringe (a build toolchain? ugh..) VSCode's inconsistent undocumented Javascript API is a pain in the butt (paste & pray driven development).
Wezterm is configured with Lua, Hammerspoon configs are also Lua.
Both are super easy to sync to multiple computers with chezmoi and the configs themselves can be smart enough to behave differently on different machines.
That's what I really love with Kate (and actually the KTextEditor component of KDE Frameworks): you can build heavy plugins in C++ but there is also a very good JavaScript API that you can write new editing commands with for example.
Lite XL (which is a project Pragtical forked on) is my first experience writing a plugin for code editor and coding in Lua, and I am surprised on how easy is it. I don't know about other editors, but in Lite XL and Pragtical I can extend or overwrite almost anything the core plugin is doing. I can even start writing the plugin in my user module file (init.lua), and see the change on the fly.
This is inspired by Emacs which works the same way. It, in turn, takes inspiration from how Lisp systems have worked since time immemorial. You're meant to open a REPL directly into the running system as a way to evolve it.
I haven't written much vscode extensions, but I've worked professionally on editors that use Monaco (the text editor library used and developed by vscode team). There's almost no documentation whatsoever.
Tangential: is there an IDE out there that supports different color schemes for each window it has open? does Pragtical? I didn't see it in the docs
I used to like having different projects open in different windows and easily differentiate between them with their color schemes. Kinda like setting a terminal to open with a random color profile
It seems like vscode and sublime want to change the scheme across all the windows.
in vscodium I have a different left bar color for each project - not exactly what you want but I can easily differentiate between them.
There is a workspace settings json file per project:
"settings": {
"workbench.colorCustomizations": {
"activityBar.background": "#faf7c7",
"activityBar.foreground": "#000000" }
}
(disclaimer: this works on Debian Gnome)
Is anyone else getting a "“Pragtical.app” is damaged and can’t be opened. You should move it to the Trash" error when attempting to run the arm64 build on macOS? Really wanted to try it out!
I suppose it could just be some security crap Corp IT installed on my laptop preventing it from installing.
It looks like it's only taking up 7.9MB in my Applications folder so it must be corrupt or something.
Haven't tried with Pragtical (hard to say it out loud BTW, lol) but have had success with right-click-opening other apps that give this error. Sometimes I need to do it multiple times to open it as normal. No issues with the apps themselves, has to do with app signing (or lack thereof for many macOS apps that one just downloads from a site).
An error about the app being damaged specifically can stem from the contents of the .app folder being modified after it was signed with the codesign tool. You can use codesign --verify (consult the man page) to get some info about why it's being considered damaged.
I've got this wrong in the past by adding the README too late in the process. Once I'd fixed that, the reason macOS gives for not opening my app became that Apple can't check it for malicious software. Much better... I think? The right click/open workaround does work.
FYI, in macOS v15 Sequoia +, Gatekeeper/quarantine/signing has changed. Right click to open won't allow the bypass. The quickest way, without disabling runtime protection:
Why fork Lite XL instead of contributing? Just out of curiosity, since I'm not familiar with either project and don't know what their respective philosophies are.
I thought for a while that TextMate bundles[1] were that, especially since JetBrains[2], Linguist[3] and VSCode[4] honor them. However, in the spirit of "the good thing about standards ..." highlight.js does[5] almost the same thing that Pragtical does which makes me feel even worse
I had high hopes for Tree-Sitter since it seems to have really won mindshare, but the idea of having an executable grammar spec[6] is ... well, no wonder it hasn't caught on outside of that specific ecosystem
Readit News
This editor claims to be lightweight, citing that it uses 30MB of RAM. But I assume that's without any extensions loaded.
Back in the day, though, one joke about Emacs was that it's an acronym for Eight Megabytes All Continuously Swapping. This was meant to highlight Emacs's reputation for bloat. Right now when I run Emacs it's using a lot more than 30, let alone eight. I'm pretty sure most of that is all the modes I have installed for every language I might ever use, regardless of whether I'm actually using it right now.
About 15 years back Visual Studio had a reputation for bloat, but my experience was that it was actually quite lightweight and snappy, especially compared to Eclipse and IntelliJ. Until you install ReSharper, which transformed it into 50 tons of molasses.
At work, Visual Studio Code currently consumes about 1GB of RAM and takes 5+ minutes to start up. On my personal computer, a 2013 MacBook, it uses more like 50MB and starts darn near instantaneously. But they're very different beasts; on my MacBook I've got it configured to only load the plugins I need for each project. At work we've got a whole dang Devcontainer that includes configuration to load I-don't-know-how-many extensions, basically anything anyone on the team has ever wanted. The devcontainer extension makes you put the list of extensions to load into a file that needs to be checked into source control. So the only way for someone to get this tool they want is to make everyone else get it, too. All to sling a relatively modest volume of Python code.
And of course if I try to opt out of all of that I make my life even harder. Trying to get by without that pile of crap is just spitting in the wind. Run-time requirements aren't documented; they're shoved into an undocumented and ever-growing list of Bash commands in the Dockerfile. Coding standards aren't documented or managed with something straightforward like Git hooks; they're enforced through a plugin and its configuration.
I do remember when vscode was lightweight. It happened to be a time when not many plugins were available. That put a hard limit on just how much bloat you could accomplish. But, of course, as soon as it got popular people started creating plugins for darn near everything.
Perhaps the problem isn't the editors. Perhaps it's us.
https://www.xkcd.com/2044/
Installing multiple programs on my computer or a server is complicated, and slows things down, and it's insecure and hard to replicate. So we created VMs. And for a while VMs were great. But then we started putting everything we needed in the VMs, and they also became complicated, and slow, and insecure and whatnot. So we have containers. And containers are now slowly getting bloated too. Kubernetes simplified some things, but now we need Helm to deal with K8s, and Helm itself is now quite complicated.
Editors start lightweight and fast, then get bloated with features. So does productivity software. Programming languages start simple and easy to use and understand, and progressively get more features, each of which seems nice in isolation, but soon the codebases use everything, and it interacts, and you need decades of experience to use it all proficiently.
Same for libraries. For network protocols. For standards of all kinds.
It's most definitely us.
Deleted Comment
Just for clarification, do you mean 50 GiB or 50 MiB? I'm assuming MiB in this scenario, since allocating 50 GiB doesn't mix with an instantaneous startup.
For coming up on a decade I've used Vim with a minimal .vimrc and no plugins. The only time I deviate from this is when I am writing in an s-expression based language. I would probably deviate from this to write Java or C#, but I haven't written either in a while.
There are upsides and downsides. The biggest upside is simply that I haven't spent ANY time learning new editors or new editor features; I'll occasionally learn about a feature of Vim that I didn't know existed, but that's very oriented toward solving immediate problems, because it tends to happen when I run into something that feels like there's probably an easier way to do it, and I'll do a quick internet search. I think a lot of devs spend a lot of time learning tools with the sense that the time spent will be paid back by time savings from using the tools, but the reality is way more hit-and-miss, and I think a lot of people could benefit from being more selective in what they spend their learning time on.
The thing that Vim completely misses is being able to jump to the appropriate file where a class/function is defined. This is more of a tradeoff than IDE folks recognize: when I was using PyCharm/IntelliJ/ReSharper, I found that being able to jump around easily would hide the fact that my projects were growing in size and complexity. The tooling makes this less painful up front, but eventually, you still feel the pain, because eventually there's some bug that cascades through a bunch of files, and you still have to reason about all of them. Finding definitions isn't the core issue with having a lot of definitions, reasoning about how they interact is the core issue, and the IDE tooling doesn't solve that. Being in Vim and having to deal with my project's file structure directly and explicitly means I feel the pain of complexity earlier, when it's easier to fix.
If I'm being honest, I'm not sure that the tradeoffs comes out in Vim's favor here. I don't think we get to have a conclusive answer because there's simply nobody who uses both vanilla Vim and the best IDEs at a high enough level to have an informed opinion about which is better. I'd say I am close because I have used both extensively, but my IDE knowledge is outdated by about a decade.
But, I've said before and I'll say again that entering text into files isn't usually the limiting factor of software development speed. If I'm mentoring a new programmer I'd rather see them learn TDD and/or how to leverage type systems and write code in Notepad, than see them write untested, unchecked code in The Best IDE/Editor Ever. Of course, there's no reason to go to those extremes.
It makes learning and navigating a new codebase much easier. So much so that it doesn't really require IDE tooling the way it does with most mainstream languages. It's harder to get lost when you always know which way is up. Consciously thinking about whether you're doing top-down or bottom-up design also flows naturally from this, for the same reason, and that seems to encourage more thoughtful, readable code design.
Is it more work? Up-front, yes, absolutely. In the long run, though? By the time I finished my first year of CS education I had already been exposed to many many examples of cases where greedy algorithms consistently produce sub-optimal results. Perhaps they aren't teaching people about that in school anymore.
That is a good point. Having IDE features like auto-import, jump to definition, etc., definitively allow for a more messy project structure.
Still, I always wonder how big projects people advocating "no IDE features" actually have worked on (or alternatively - if they are some sort of memory savants). One thing is a small-medium sized personal project. Another is a 10-20 man cooperation where you have only written a portion of the code, and a big chunk of that is a long time since you written. IMO that require lots of code reading, which is very painful without jump to definition... I don't really see how a perfect project organization could sufficiently remove that reading friction.
ctags+cscope in vim is great at this!
Dead Comment
Writing extensions in Lua is huge. (Same as OBS) Looks very simple and productive.
It's one of the main reasons I've stuck to Sublime... extending with Python is very easy and works everywhere.
Even if both Zed and VSCode are strong in other areas.. Rust extensions makes me cringe (a build toolchain? ugh..) VSCode's inconsistent undocumented Javascript API is a pain in the butt (paste & pray driven development).
Will be keeping an eye on this.
It's so bad they have a whole Github Copilot mode specifically dedicated to it. Pay and pray driven development.
Both are super easy to sync to multiple computers with chezmoi and the configs themselves can be smart enough to behave differently on different machines.
I wish more software used Lua for config.
Or Tcl, which I used 20 years ago as for our in-house proxy module for Apache/IIS, extensible in C and Tcl.
Unfortunely out of fashion for anyone besides EDA tooling.
I really liked Lite XL but back when I looked at it it was a challenge to understand it’s API and functionality.
Looking forward to give this a spin!
I used to like having different projects open in different windows and easily differentiate between them with their color schemes. Kinda like setting a terminal to open with a random color profile
It seems like vscode and sublime want to change the scheme across all the windows.
I suppose it could just be some security crap Corp IT installed on my laptop preventing it from installing.
It looks like it's only taking up 7.9MB in my Applications folder so it must be corrupt or something.
``` cd /Applications/DBeaver.app/; ls -@l ```
And then if you see some extended attributes like quarantine and provenance, you can remove them
``` xattr -d com.apple.provenance DBWeaver.app/; xattr -d com.apple.quarantine DBWeaver.app/ ```
Deleted Comment
I've got this wrong in the past by adding the README too late in the process. Once I'd fixed that, the reason macOS gives for not opening my app became that Apple can't check it for malicious software. Much better... I think? The right click/open workaround does work.
`xattr -r -d com.apple.quarantine /Applications/Pragtical.app`
-d is delete -r is recursive
Hopefully, Apple won't lock it down further.
[0] https://github.com/pragtical/pragtical/issues/6#issuecomment...
I thought for a while that TextMate bundles[1] were that, especially since JetBrains[2], Linguist[3] and VSCode[4] honor them. However, in the spirit of "the good thing about standards ..." highlight.js does[5] almost the same thing that Pragtical does which makes me feel even worse
I had high hopes for Tree-Sitter since it seems to have really won mindshare, but the idea of having an executable grammar spec[6] is ... well, no wonder it hasn't caught on outside of that specific ecosystem
1: https://github.com/rspec/rspec.tmbundle/blob/1.1.12/Syntaxes...
2: https://github.com/JetBrains/intellij-community/blob/idea/24...
3: https://github.com/github-linguist/linguist/blob/v7.30.0/lib...
4: https://github.com/microsoft/vscode-textmate
5: https://github.com/highlightjs/highlight.js/blob/11.10.0/src...
6: https://github.com/tree-sitter/tree-sitter/blob/v0.22.6/test...