My IDE is too heavy so I moved to Emacs | Hacker News Reader

My IDE is too heavy so I moved to Emacs

renato.athaydes.com

263 pointslycopodiopsida287 comments

As an emacs user I have to say that IntelliJ (and pretty much any modern IDE) feels snappier than emacs configured to do anything comparable (lsp-mode/eglot, corfu/company, tree-sitter etc).

While IDEs may require more resources, they usually utilize them better.

Emacs is fundamentally single-threaded and not great at async things. With most of the logic written in a very slow non-JIT friendly language with naive blocking GC. Rendering pipeline is also a mess. Underlying internal datastructures are also very naive (which is a good thing when you implement things in C).

Things are slowly changing. emacs now is a lot better than 5 years. So may be in 10 years it will really rival more modern competitors in terms of performance.

Having said all this, emacs universality and extensibility keep me with it.

The asyncness of Intellij IDEs annoys me at times. I'm used (from emacs) to bashing out a series of key combinations in the expectation that the effects of one will be complete before the next is processed. There are cases in Intellij IDEs (can't remember specifics, I'm blissfully back in emacsland and don't anticipate using an IDE again in the near future) where that can result in the later keypresses being processed before the window pops up or whatever from the earlier ones.

Just a minor annoyance, really. It would be nice for emacs to improve on the async front, but synchronicity does have its benefits when interacting with humans. I sometimes find the lack of asynchronous behaviour annoying in emacs, but not very often despite using EXWM (so locking up emacs means locking up the window manager).

I use IdeaVim on a Mac and I'm 80% sure it reorders keystrokes sometimes when I go between normal and insert mode.

I've never had this happen to me. Could you describe what happens a bit more clearly? Now I'm curious.

E.g. I'm in insert mode, then I press esc to go to normal mode and press j to go down one line. Instead, j is inserted.

I can't be sure I didn't just make a typo, but this has happened much more often in Intellij than in vim proper, so I think there is something going on where IDEA has a hiccup and scrambles or eats some inputs.

You can lower the autocomplete time threshold.

This is a major annoyance in Visual Studio. You have to stay all the time waiting for feedback from the software, otherwise your commands will get processed on the wrong order.

And yes, autocompletion fires from many different keys, and if it misses the keys order, it will automplete into some completely different code.

Doesn't lsp run in a separate process for other editors as well? I've only found emacs slow for larger Java projects in the past, using eclim, and font-locking very large javascript files. But the new lsp-java seems to have cleared that up, and I'm not sure what changed w/ javascript-mode, but it also seems much faster since a few years ago.

LSP runs in a separate process, but handling that process is synchronous in Emacs, I think. So if LSP is slow for something, Emacs will block.

Yes it gives us both a super-predictable queued operations model for using emacs, and serial operation in a parallel world. Years ago when single core performance was king this wasn't an issue, but now we're stuck having to optimize the long hot path.

The next AMD processor should have an optional Emacs dedicated core.

Since you mentioned the single-threadedness (and it’s relevant to the discussion of IDE/Emacs): what’s the status of any initiative to move Emacs to multiple cores? I’m single, and I hope to one day have a family etc.. If I end up staying single for long enough, helping move Emacs onto multiple cores is something I fantasize about contributing back to the community that has helped my life so much.

Does anyone have any input?

Most of what Emacs does just won’t benefit from massive parallelism. CPUs are ridiculously fast at processing text (AVX2 instructions can process vectors of 32 bytes at a time), and most of the stuff that _can_ benefit from parallelism should just be moved to an external process. For example, querying your compiler for a list of methods that apply to the current object, or a list of functions that start with “Foo” are mostly moving to external processes using LSP as the communication protocol. It would be nice for some things to use background threads, like Gnus polling your IMAP server for email, and Emacs does have the threading mechanisms to handle that now. It’s just a matter of time before someone does the work :)

Hey! Exactly the response I was looking for. Thanks for this.

Your response reminded me of an Intel project about regular expressions. I think it’s called hyperscan, but I’m not sure. It’s a regex engine (I think that’s the correct terminology) that makes dedicated use of very specific Intel instructions to reach incredible regex speeds on Intel processors. Would be cool if Emacs could make use of this tech when configured properly. I bet there are some internals that rely on regex.

Does emacs use specialized instruction sets like AVX2?

Ha! No. Native compilation just snuck in a little while ago. SIMD will take... longer.

Alas, no. But the power is right there, all we have to is stretch forth our hands and use it.

I disagree. When I am running a compilation (with output being dumped into a visible buffer) + query magit for large commit. Over tramp. Things noticeably freeze. Technically it all is async. Practically, it is implemented as polling things on main thread with some witing happening in non-async fashion.

> For example, querying your compiler for a list of methods that apply to the current object, or a list of functions that start with “Foo” are mostly moving to external processes using LSP as the communication protocol.

That's why we have lsp-bridge and lsp-mode emacs fork :) Both of which build some infrastructure to avoid doing communication work with lsp-mode work in main emacs thread. So, heavy emacs users are building some async machinery which wraps another already async and relatively lightweight protocol, because core emacs facilities can't keep up with it. Architecturally it is kind of insane.

I think, lsp-mode fork is doing the right thing (from practical POV; it goes against "emacs is just an elisp interpreter" ideology though) and hope it gets into core at some point. A better solution would have being having first class async and background threads support at the elisp level. Which would never happen due to elisp messiness.

https://github.com/emacs-lsp/emacs https://github.com/manateelazycat/lsp-bridge

Emacs has support for multithreading (threads landed in 26), there was an article about the multithreaded model earlier this year (https://news.ycombinator.com/item?id=31559818), and the Elisp manual has a section on concurrency (section "Threads").

If you want to contribute to the future (pun intended) of multithreaded Emacs, your best bet may be to make a library that adds the nice concurrency facilities that will help library authors move to a multithreaded model. An actor model, green threads, or supervision trees may be avenues worth pursuing.

A big blocker is probably the dynamic binding, but trying to "fix" that would break a lot, if not all, of the existing libraries.

Thanks for the pleasant surprise of encouraging feedback. I’m going to send this comment chain to my email inbox so that I can find it later. This is great.

It’s such a monumental task to hack on the basics of the text editing. I listened to a tts book; I think it was titled “The Art of the Text Editor” that delved a bit into some of the original philosophy of the text rendering etc. in Emacs. You might enjoy it If you ever need a boring book to read.

You probably mean The Craft of Text Editing -or- A Cookbook for an Emacs. I've skimmed it a bit before and it's on my reading list. First I'm still working my way through CRLS's Introduction to Algorithms and Aspnes' Notes on Data Structures and Programming Techniques.

Links to the electronic versions of this out of print book: https://www.finseth.com/craft/

Warning, low self-esteem and anxiety ahead:

I really wish I had the capacity and capability to pursue this effort. I barely have the energy to be good at shitty DevOps and Terraform, writing basic Python and Node is so time consuming. I can do some Lisp, but only at the basic level of init.el and adapting a few configuration examples.

I do the good thing and donate to the FSF monthly but I wish I could donate directly to Emacs because I use it every day. Even better would be to sponsor the development of a concurrency library and port of major things like magit or org.

> I wish I could donate directly to Emacs

I've requested this whenever I've had the chance. I would be very happy to donate some cash to get core Emacs improved. Emacs has made a huge positive difference to my professional life for years. Unfortunately this is not made easy.

I think one of the issues last time I looked into it was that FSF couldn't have donations on a platform that was potentially tarnished by having e.g. non-free javascript running on it somewhere... All very correct and in tune with their mission I'm sure, and part of the reason why Emacs etc. has been so successful, but it would be nice if they were a bit more pragmatic occasionally.

Please DON'T use the threads. As of 2018 it has many data races (https://nullprogram.com/blog/2018/05/31/), and resultant bugs will be a nightmare to track down.

The Emacs community has always got by through finding other ways to ensure responsiveness. It's true that each individual user shouldn't have to spend that much time on configuration (Doom Emacs and such distros help here), but still: people who find it slow must have misconfigured something, and on profiling, they'll find at most 1 or 2 features of their config that's eating all the CPU cycles. These won't actually be hard to fix, for a programmer, and threads wouldn't have helped matters, and at best only have hid the CPU-eater.

Yes, that post was mentioned in the article I linked:

Even Emacs current threads library suffers from data races which is one of the reason I believe it has not seen much adoption.

(where suffers from data races is a link to Chris Wellons' post).

The idea now is, as Chris states:

There really needs to be a safe, high-level API with clean thread isolation. Perhaps this higher-level API will eventually build on top of the low-level threading API.

While you are right that for 99% of standard usage single-threaded code is entirely fine, not utilizing between half to 15/16ths of potential processing power is a bit of a shame, especially considering it means doing something like indexing an entire project (yes, we can use GNU Global) will require the user to just sit and wait.

That "99% of standard usage" is the kicker, isn't it? The greybeards who opposed multithreading since the beginning tend to say that the remaining 1% of use cases is best done in an external process, ideally not even written in Emacs Lisp, so that Vimmers and the rest of the free software community can benefit. The GNU Global you mention embodies that ideal exactly.

I suppose if you still want that program to be written with Emacs Lisp, you could use async.el (https://github.com/jwiegley/emacs-async/) and there's finally an use-case for the threads: it'll be relatively safe to run those 16 threads only in the external Emacs-process.

Emacs now has AoT compilation of EmacsLisp, using GCC's JIT library:

https://blog.phundrak.com/emacs-29-what-can-we-expect/

This is awesome! I use it since initial "gccemacs" announcements.

It is still order of magnitude slower than JS. Dynamic binding, ability to redefine or advice any function and fundamentally cache-unfriendly core datastructures (cons-cells) and absence of JIT hotspot optimization do not help to catch up with competition :(

Yeah, Emacs's performance isn't really that great when going head-to-head as an IDE. Yes, it uses less memory and disk cache, but if we're talking about, e.g., working on a large Rust project with Emacs+lsp-mode/eglot+rust-analyzer, you're going to be in the ballpark of IntelliJ for memory usage, and the responsiveness will be nowhere near it. I will say, though, that the disk usage will be much less, and that has mattered for me on this 256GB disk MBP- between Xcode, Docker, and all these package managers for various languages, my disk space has become a precious commodity.

I still like Emacs. I prefer free software. I love Magit. But, the UI responsiveness is honestly frustrating when using LSP.

For me Emacs pretty much grinds to a halt if I turn on showing line numbers.

You’re probably using the old notoriously slow linum-mode. The newer line-number-mode is much snappier.

Try to determine which one you're using by running "M-x linum-mode" and then "M-x display-line-numbers-mode". Note that you can use both at the same time (which would make zero sense: it's only to troubleshoot which one is problematic for you).

Do not use linum-mode anymore.

I can display buffers with hundreds of thousands of lines while showing the line numbers (Emacs 29 / native compilation / display-line-numbers-mode / CPU is an AMD 3700X with 32 GB of RAM) and Emacs is ultra responsive.

This is the kind of thing which infuriates me the most about emacs. There are thousands of similar but not equivalent ways of doing the same thing, both StackOverflow and the emacs wiki contains some (but not all, and not the same, and usually not the right, and usually contradictory) ways of doing things. And it's impossible to figure out which way is the right one without asking around in IRC channels.

Why oh why couldn't they improve linenum-mode instead of introducing a new mode.

> There are thousands of similar but not equivalent ways of doing the same thing, both StackOverflow and the emacs wiki contains some

What about the manual?

https://www.gnu.org/software/emacs/manual/html_node/emacs/Di...

The issues you described are mostly totally solved by looking in the manual first rather than externally.

> Why oh why couldn't they improve linenum-mode instead of introducing a new mode.

The double-edged sword of being very backwards compatible.

Wouldn't most of the slowness and memory use be due to rust-analyzer itself, which is notoriously slow and heavy for large projects? That has little to do with your IDE choice. Emacs devs are also working on tree-sitter parsing support, which might help reduce reliance on LSP more generally.

Emacs was built as a TUI, and it is built like a giant REPL; read input, evaluate command, print the output, and loop back. IDEs based on "modern" GUI frameworks (IntelliJ uses Swing, not exactly "modern") are inherently multi-threaded; you have the UI (or "main") thread that accepts events and updates the display, and ideally never blocks, while evaluation is performed on worker threads that can be canceled or scheduled as needed.

In practice, you can get far with Emacs' process supervision to avoid blocking the command loop, but some things that are trivial to offload to a worker thread are next-to-impossible to avoid blocking in Emacs. One of those things is parsing megabytes of JSON from an LSP server into Lisp data structures, which is baked into the Emacs core and will block redisplay.

Yes and no. I'm using rust-analyzer as an example, but I also use other language servers and observe similar UI lags/stutters.

When it comes to memory, my point is precisely that we should count the language server in the total and not just the Emacs process. So, when some other IDE is using multiple GB of memory on my Rust project, we have to compare that to my Emacs + rust-analyzer memory usage because both of those processes are providing the features that other-IDE is providing.

However, Emacs is also still kind of laggy when using LSP, even though the actual LSP server lives in another process and communicates mostly asynchronously. My understanding is that there are still bottlenecks in Emacs that make this not truly async. But, even if my LSP server of choice is extremely slow, why should that affect my cursor movement or typing speed in my Emacs buffer? I can see why it would be technically difficult to make it NOT introduce some lag, but it shouldn't in principle.

I haven't used Visual Studio Code, but my understanding is that it is plenty responsive to typing and cursor movement, even while using rust-analyzer.

For anything lsp related, this fork by the lsp authors has been noticeably snappier and more pleasant to use for me (large rust project): https://old.reddit.com/r/emacs/comments/ymrkyn/async_nonbloc...

It moves the json rpc stuff to be async, and makes a real difference in terms of perceived performance.

This.

I tried to switch to Emacs multiple times, but the lagginess in a non-trivial setup just kills me.

I always went back to Neovim.

I tried to switch to emacs but couldn't find an introductory tutorial that was written for mere mortals.

Currently use vim, or things like gedit and kate that come w/ a DE. I would really like to learn to use emacs, but the last so called "beginner" tutorial I tried started with _learn a new lisp dialect so you can write emacs extensions_. Seriously.

Does anyone know where to find a tutorial that teaches you how to do things like open a file, type some stuff, and save the file?

Maybe show whitespace change highlighting modes and a few hotkeys if I want to get fancy... but like otherwise normal beginner stuff?

Maybe https://emacs.zeef.com might be your friend? There are some tutorials listed there for Emacs.

There's a built-in tutorial, called by pressing ctrl-h (or f1) and then t.

Aside from the built in docs, mastering emacs is quite beginner friendly. It's aimed at people with prior programming experience, but not any emacs experience. You can get a few chapters for free.

I assume I'll use emacs as long as I continue to use computers, and it's been decades since I thought editors really should be written in assembler, but this:

"I use an underpowered MacBook Air from around 2019"

and this:

"Mac M1 with 64GB of RAM and 10 CPU cores, everything feels lightweight"

are insane sentiments to express, and it's an insane world that makes those thoughts seem agreeable to anyone.

There is zero justification to consider a 2019 Air "underpowered" for this task. There is zero justification to consider that of course one needs an obscenely powerful portable supercomputer for this task.

IDEs do a lot. They do NOT do enough to justify this insanity.

I'm sure there's an element of people not knowing what's been lost, and an element of people not understanding just how inconceivably fast computers are today, but it's hard to wrap the brain around anyone tolerating this (as customers, as purchasers, as users).

Perhaps the same sort of jaw-drop that occurs when someone takes a naive python app to go or rust and discovers that python is in fact actually really slow (whether or not it's "fast enough")?

Get off my porch, whippersnappers, etc etc.

Well a modern IDE does way more than an IDE 10 years ago. E.g. I expect full text search that is pretty much instant. I remember times when a full search took multiple seconds to complete. Compilers for heavily typed languages are constantly re-compiling my code while I'm typing. Decent autocompletion has to perform tasks that are usually only required of a compiler. Code comments are converted into formatted documentation instantly, always available when I look for it. Device and build processes are monitored, git status is kept up to date, etc etc

> Well a modern IDE does way more than an IDE 10 years ago.

Really? Like what? What types of refactoring, indexing and completion features does IntelliJ have that it didn’t in 2013?

The best answer to this is look at the VS Code ecosystem (as Intellij is niche by a small number of developers). In that ecosystem you will have all kinds of plugins from things watching and notifiying you about pipeline status to things like DVC, etc that allow things that you couldn't do, at least not without severe side effects back in 2013.

The best thing to do is not look to the people reinventing the wheel. There are tons of new features in IntelliJ since 2013 including support for things like Go and Rust.

A modern IDE does nearly all the ai hype hopes to achieve, minus code completion. It reviews code, auto completes, hints good practice, searched code real fast, etc.

IntelliJ was doing all that 10 years ago.

Here’s a current changelog, looks like quite a few CPU eating features have been added: https://www.jetbrains.com/idea/whatsnew/

I don’t see what you’re talking about. A bunch claim to be performance improvements - there are some additional features for language plugins that are similar to those that have already exist for other languages such as better completion (a language plugin completion/refactoring features shouldn’t be eating much CPU if that’s not the active file one is working with). A few more Java inspections, some Spring and Kotlin niceties, etc. All incremental. Most of these should not be terribly CPU eating with the existing infrastructure. Search Everywhere and Find Usages at their core have been there far longer than a decade.

Seriously what is this major new infrastructural component in the past 10 years? One could argue these AI code things, but they’re mostly cloud.

I never wrote about new infrastructural components, you argued yourself into that corner. I wanted to express that IDEs have grown way more complex and capable, and that this added capability might explain why modern systems are needed to get a snappy experience out of them.

I’m saying the complexity of IDEs such as IntelliJ is concentrated in their base infrastructure of indexing and refactoring engine and that hasn’t changed all that much in the past decade. That there are more and more new language plugins and some nice UX features built on this core do not reflect some major new complexity in the past decade.

New language plugins and some incremental features that usually only cost when you use them have been added continuously for years.

IntelliJ was already capable in 2010. Your initial example was about fast global search - a feature available for more than 10 years.

If you are vaguely familiar with big software cores like the Linux kernel, you‘ll realize that extensions are often not „clean“ and need changes in the core, too. Yes, the Linux kernel is still super performant and runs on very old hardware, but you wouldn’t be able to run all those new features on old hardware that the kernel has accommodated since.

Entertaining, because I still run IntelliJ and CLion on a decade old Lenovo T430 running Linux with nothing more than a RAM upgrade and overall it works more smoothly now than it did 10 years ago.

This is due as much due to massive. improvements in the JRE itself over that time period in addition to IntelliJ itself.

I’m vaguely familiar with the Linux kernel enough to write drivers and contribute the odd mm or vfs patch over the years. But more pertinent - I develop an IntelliJ plugin.

I was asking for something specific and the response just gets more vague.

MacOS is probably not helping that 2019 MacBook Air feel responsive. I have a Dell that's a little older than that running Linux and it doesn't feel slow or sluggish.

wow when i read that, i thought the op said "MacBook Air from around 2009". i have the same M1 laptop and do not consider it underpowered at all !

The target market is enterprise. If I showed up for my first day of work and they handed me a 2019 MacBook Air I'd be pretty unhappy.

I really don't get this attitude of indignation when a powerful machine's resources are fully utilized. What else are you doing with with that computing power? There's not some finite pool of computing power we are depleting here, they are figuring out how to make more all the time!

Equality of access to compute around the world could be a principle pointing towards doing more with less.

The problem isn't that people are hogging all the CPU, the problem is that it's hard to get computers to people around the world, connect them to infrastructure (power, internet), and train people to use them. Plenty of smart people have actively tried to solve this problem and have failed. I'm not sure if adopting such a principle means anything whatsoever in the face of what appears to be a larger challenge than providing computing power to a willing yet deprived population.

The 2019 Air is underpowered (1.6 GHz Dual-Core, 7W TDP[1]) even when comparing it to more affordable hardware from 2019 or secondary market business laptops from the prior 5 years or so.

[1]: https://www.intel.com/content/www/us/en/products/sku/189912/...

It's your right as a consumer to have a pro-consumption attitude, because you're spending your own money. Be thrifty. Be profligate. You choose.

But having it as a developer is a different matter. That "powerful machine's resources" aren't yours. They belong to your customer, and it isn't your business what your customer is doing with the computing power your program isn't using.

Writing programs that demand more resources than necessary forces people to discard and replace otherwise perfectly good computers. Which, again, you as the developer don't have to pay for.

If tragedies of the commons don't bug you, then none of this matters. But if they do, then imagine millions of people ordering millions of cardboard boxes from Amazon containing millions of sticks of DRAM to run that O(n^4) loop that you're about to check in.

I can sympathize with this attitude with things like a Slack clients, which are designed to run in the background, and which developers probably don’t have much choice over.

But there are plenty of lightweight IDE options. IntelliJ competes to be the most powerful IDE available. That implies using lots of compute resources for productivity gains that might be marginal or not even realized by all devs.

"Get off my porch, whippersnappers, etc etc."

I'm only in my early 30's and share this sentiment already.

Tech sure moves fast...

I'm still on Sublime Text, after briefly switching to VSCode. Unless you're on latest-gen hardware it seems that most feature-rich IDEs are just terribly laggy, which drives me nuts. A computer just shouldn't need several seconds to load and parse a source file even if it has 100.000 lines. Editors like Emacs or Vim were always too low-level for me though, Sublime is a nice compromise between simplicity and speed.

I tried to switch from Sublime to VSCode as well, and it's mostly been a disappointment.

Really? I did the switch and there’s no way I could go back to ST.

Agreed. I loved Sublime for years but VS Code is now miles ahead in my opinion.

In what ways do you think VS Code is miles ahead? With language server and debug adapter plugins, I find ST to be a very good replacement for VS Code.

All the plugins, The synced user configuration, github copilot, git integration (although I do use sublime merge a lot on the side), I used to work on a remote copy also via SSH (and I can't remember what plugin), there's just so much available out of vscode now, I feel like every new months it ships new features while sublime text didn't come up with an update in years.

For me it is the plugins, themes, icons etc. As soon as there is a plugin you can't live without, there's no way back. I can't remember which one it was for me but when I saw a co-worker using it I had to give VS Code another try.

Migrating over is easy too as you can import your shortcuts with "Sublime Text Keymap and Settings Importer"

Sublime still feels a bit snappier to me. The ecosystem around it has obviously fallen behind a bit now though.

Only partially true. The ecosystem has some really awesome plugins: - GitSavvy - Sublime-LSP (plus LSP-Copilot) - Sublime_Debugger - Terminus

All these together and you have a keyboard driven ultrafast IDElike experience.

I'm in the market for a new IDE as Atom is end of life (prev. Sublime)

I tried VSCode and went back to Atom -- it still works fine but expecting that won't last

Ideally I really need one where I can run bash sessions in tabs alongside code, I don't really use autocomplete and such -- but it needs to handle a lot of open large files with zero lag and instant search

>Ideally I really need one where I can run bash sessions in tabs alongside code,

Wouldn't it easily be solved if people were actually using decent desktop environment or take the time to configure it correctly?

I mean it is not complicated to move from ide to terminal if the desktop and shortcuts are well made.

I switched from Atom to VSCode a while back. Code has better extensions and is faster. Only thing that bothered me is the missing Git view on right side. But now Code lets you have a Primary and Secondary sidebars. I keep Git on right side and File Explorer on left side

I moved from Atom to VSCode a few years ago. It's a worthy successor, in my opinion.

What were your blockers to moving to VSCode? My remaining issue is to be able to css style any element of the UI like I could with Atom. There're plugins that let you monkey patch to get that feature, but updates to VSCode break them.

Too many windows, panes, misfeatures I don't want, and it's also quite slow.

It's a kitchen sink even before you install any plugins, and yet all the useful functionality requires plugins.

All I want is a text editor that can quickly switch to another file, that doesn't make it annoying when the file it had open was changed, that only adds the input that I type to a file and nothing else.

Also easy integration with commandline tools (select text, pass that as stdin to a command, replace it with stdout, all done trivially without going through a billion menus and plugins), vertical selection and multi-cursor that doesn't suck, maybe a few other details, are things where it failed to deliver.

I think Pulsar might be interesting: https://pulsar-edit.dev/

I understand these are some folks trying to keep Atom alive.

Vscode now allows terminal to be in editor area along with files.

All the code I work on is hosted on a separate development server, so I used to use Sublime to edit these files over the network, using NFS.

But now I use code-server, which is hosted on the same development server. So everything got a lot faster for me.

> A computer just shouldn't need several seconds to load and parse a source file even if it has 100.000 lines.

Why? It doesn't just load the file, but also analyze it, find flaws and put it into a bigger picture which assists the user. And you don't need a last gen for this. I work on a 10 year old machine quite fine with a rather heavy IDE-Setup. Just accept that a computer can be your partner, helping you to reach your goal, and that he needs his time for doing his work too.

Because your are not viewing those 100k lines at once ever. Taking that into consideration, enormous optimizations are possible.

The lines are all interconnected. Whether you view them or not, they still influence each in some way or another. And figuring this out is the hard part in coding and software-design, which the computer takes care of and assists you.

All the lines being interconnected is a rare edge-case. Often there are multiple independent top level expressions in a file. Talking about code here, because that is the most common thing that needs to be highlighted and where lines influence each other potentially.

To make a simple example: Have multiple functions defined at the top level of the file? Great! Independent parts!

Of course it could be, that in one function another is called, but does that have to affect highlighting? Immediately?

The code model still needs to be built from the entire file, which I suspect is what most of the slowdown is when using an IDE (not highlighting, although the code model can inform advanced highlighting e.g. different colors for local vs instance vars).

Well, that is no justification for any slowdown. The "code model" does not need to be complete the moment I start an IDE or open a file or project in it. A temporarily incomplete model is very acceptable. More work can be put off to a background thread. It can be delayed until I perform the first action, that actually needs a complete model, like say a renaming of something. There are relatively few actions like that. Many facts can already be concluded from import statements in various languages.

Furthermore we are fighting a strawman here: Who in their right mind opens a 100k line code file in an IDE? And who in their right mind creates such a disaster in the first place? This is not a realistic scenario we are talking about here.

I love these weird, artificial "no true Scotsman" arguments that appear on HN when people are discussing little more than the colour of the bike shed. "Oh, but how does it do with 100k lines?" I can already tell you from my lovely, bloated IDE: Terrible. And, I don't care. Why? WTF is this file 100k lines!?

I know at my workplace, the vim&emacs-users are the reason for the codesinks here. They have no relevant penalty for growing everything in singles files, but they have some benefit as they can navigate code better with a poor setup. And at some point, reasons like "not destroying the git-history" and such are added to the list. And laziness might be another reason on that list.

I took the same journey. I switched from Sublime Text to VSCode and stuck with VSCode for months, and depending on project du jour I've done this a couple of times. For me its mostly speed and a number of small, but frequently encountered, quality of life issues that keep me coming back to Sublime Text. Some of the small differences around cursor/multi-cursor management never stop irritating me in VSCode compared to ST. Also, I do a lot of PostgreSQL related stuff and I've yet to find a syntax highlighter that's 1) just syntax highlighting; and 2) able to handle things like dollar quoting well for VSCode where in Sublime Text I've had such highlighting for years.

Sure it doesn't see frequent updates... but so what? That might well be a strength since some kinds of changes can be low value & highly disorienting. The plug in eco-system isn't as broad as that for VSCode, but unsurprisingly there's more cruft there, too.

Ultimately your mileage will vary based on your preferences, but I'll stick with Sublime Text until there's something really more compelling.

Interesting, it was mutlicursor bugs in SublimeText that never got fixed the drove me to finally switch to VSCode.

ST dev here, what multicursor bugs specifically?

> ST dev

Just wanted to say thank you for a fantastic text editor. It feels like a superpower when I show it to non-tech people

> Just wanted to say thank you for a fantastic text editor.

This. ST has been my best coding tool for the last few years. A keeper. Thank you!

First off, thanks for years of productive development with ST. I really enjoyed using your software for a long time and it carried me through a significant portion of my early career.

It was a bug where selecting some text and using the key shortcut to multi select the next instance would select incorrect text for certain strings. It was a while ago so I don't remember the details, it may have been some combos of whitespace and non-alphanumeric characters.

It wasn't the only reason, but it was the final impetus to try some other solutions.

Here's an annoying one: https://github.com/sublimehq/sublime_text/issues/1054

ah yeah, that one has me disabling word wrapping on files where I wouldn't otherwise.

Hasn't been enough motivation to leave ST though

I don't really know what you do with your text editor, but Emacs (and vim) are very much not "low-level" editors unless you chose to not configure them.

Emacs has all the features of VScode, plus more. And it keeps expanding by each day. A "fully featured" Emacs "IDE" is also just as laggy, sometimes even more, as any other "fully featured" IDE. Some Emacs configs even take tens of seconds to load! Mine however takes 1.5s, but that is because everything is lazily loaded. The first time I open a C++ file, it takes a couple seconds.

A really nice easy to use framework for getting productive in Emacs quickly is Doom[1]. You should give it a peak if you think Emacs is "low-level".

[1] https://github.com/doomemacs/doomemacs

What is doom equivalent in vim?

https://github.com/NTBBloodbath/doom-nvim

After all these years, sublime still stands on a league of its own.

Fleet is supposed to be this lightweight editor but unless it can beat sublime at startup, it's not.

One of only about three things I miss from switching away from Windows, is that I now have to use Sublime instead of Notepad++. It was just so much better at dealing with large files and batch operations, which are a priority for my work. But Sublime has beat everything else I have tried out on Linux, and obviously has features Notepad++ does not.

> IntelliJ is a great product and I don’t even consider switching to anything else for professional development, where having the greatest laptop and the best tools possible should be a priority.

The title should really be "My IDE is too heavy so I moved to Emacs for hobby projects".

That's less click-baity, though.

Yes, I agree. And to add my two cents, if you are living in a wealthy country and/or working for an established, stable firm, you should have an IDE with the world's worst case of type 2 diabetes: 8+ CPU cores, 16+GB RAM, PCIe 3.0+ NVMe. (Double is more ideal.) Gluttony! Except as a golf-like sport, I never understand the obsession with "lightweight" development environments. Like Protoss and Zerg, it would be fun to watch eSports-style coding exercises with type 2 diabetes IDE vs vim/emacs + plugins. Example ridiculous exercise: Refactor this bloated enterprisey Java mess to upgrade from Spring Framework version X to Y. Only slighly joking here, but the vim/emacs setup would be smoking at the hood. The IDE would need a few mins of indexing, then off to the races!

> Example ridiculous exercise: Refactor this bloated enterprisey Java mess to upgrade from Spring Framework version X to Y. Only slighly joking here, but the vim/emacs setup would be smoking at the hood. The IDE would need a few mins of indexing, then off to the races!

It's hard for me to come up with examples where the emacs setup wouldn't already be done in a couple minutes or using grep and a writeable grep buffer.

A long time ago I switched to Emacs(with evil mode) from whatever IDEs I was using but it was also way too slow. I then switched to vim and configured it with lots of plugins. This was the best thing ever. I transitioned to Neovim but Vim would also be OK.

Vim/Neovim are always fast. Even with 30+ plugins configured. I can run them on any hardware and they are blazing fast. Not to mention the superiority of modal editing if you are used to it. I have every feature I need (LSP/code completion/diagnostics/even debugging via DAP).

Pretty sure that I won't switch setup for a long time/ever again.

https://spacevim.org/ is also good alternative , it is basically vim/neovim sensible plugins pre-configured with smaller config file and simpler management.

Also see:

https://www.lunarvim.org/

https://nvchad.com/

+1 to LunarVim, I use it daily. It has sensible default shortcuts and plugins. I think I have configured maybe 2 things in the last few years.

astrovim is really good as well

I suggest that everyone go through this journey before using Neovim: https://www.chrisatmachine.com (so you can understand how and why something works, and also fine-tune your setup). Chrisatmachine's setup as for me looks similar to AstroVim.

Oh this feels like spacemacs I already use evil mode spacemacs I think the most important feature is org mode but maybe I’ll play with spacevim over the holidays!

Thank you, that's just what I was looking for!

There are many of these distributions and I recommend them to people new to Vim because they can get a good out-of-the-box experience.

However after some time you probably want to configure your own and only include what you truly need. For this a good solution is to just adapt https://github.com/LunarVim/nvim-basic-ide to your liking. This is made by the author(s) of LunarVim.

Then you couple this with IdeaVim and complement by running JetBrains IDEs on the side

This sounds like exactly what I wouldn't do?! I actively stay away from IDEs because the are bloated and slow and don't offer me personally anything that I am missing in my (configured) Vim.

I have used JetBrains in the past and I never was a fan. It is very slow and lagy in many situations. If I'd go the "IDE" route vscode would be my choice.

Same here except that each year it seems like I shed a plug-in that I’m not using anymore. Over the last decade I’ve been told over and over whenever I join a new team that Vim isn’t going to cut it and I should switch to the current hotness. Invariably, I give the new hotness an honest shake and can’t suffer the productivity hit. My favorite is when someone promises me that the “vim bindings” are actually really good.

What I think people don’t get is that it’s not just Vim. You can add hjkl to another editor and it doesn’t make a difference. The terminal is my IDE. I run vim within tmux side by side with a shell, and I’m way faster at grepping for something than IntelliJ is at indexing and searching. My editor never has a few-second lockup. I never depend on the IDE to build my code, so when I work on something there’s a functioning Makefile or equivalent and it’s inherently ready to build and test on CI.

I don’t care about Vim vs emacs. I’m sure emacs is great if you’ve invested in it like I have vim. But contrary to all the IDEs and editors I’ve been urged to switch to over the last ten years, vim is still kicking and I keep getting better with it. If I adopted the new hotness every few years that wouldn’t be the case. You can pry vim from my cold dead fingers.

What Jetbrains provides, and is quite hard to replicate, is the linting and auto-correct suite for medium/large/enterprise development teams.

That's actually the main thing, deep and wide integrated linting.

Almost everyone does autocompletion (up to a point).

Almost no one does linting as well as they do.

Quick experiment for you.

Take a big source code file you've worked on, preferably solo, so you won't have excuses :-p Not a "best case scenario" file you've cleaned up and polished. Be honest with yourself, something big and reasonably messy where the deadline was tight or the issue was complex.

Open the entire project and configure it in a Jetbrains product.

Open that specific file in the IDE.

My guess is that the top-right green checkmark won't be there.

You just can't hold all that stuff in your head at all times.

That's why we use computers and tools (such as advanced IDEs), to remind us of this stuff.

Anyway, in the rare case that you actually do all of that on your own, <<you>> are an outlier. 1%, 10%, for sure you're not lower than 50% of developers. The majority of developers need that help.

That's an expensive experiment to try, so I probably won't do it, but what does the green arrow checkmark mean? That my code lints? I use Syntastic most of the time, which just runs a linter like flake8 and then puts a red arrow next to offending lines. It runs every time I save, and I generally take its feedback right away because the slight shift to the right when the arrows are present nudges me to fix them.

Definitely not saying anyone else should use Vim if they don't want to, just that Vim is part of my productivity superpower and I take offense to it when part of the onboarding experience is setting up an IDE and someone really pushes it on me.

Yes, the green checkmars means that the code is lint-free (up to a point).

The Jetbrains linters are proprietary, though they can integrate Open Source ones, and generally better and more thorough than Open Source ones. They're especially better for professional development where you use various frameworks.

> I take offense to it when part of the onboarding experience is setting up an IDE and someone really pushes it on me.

That's fine, but being a part of a team sometimes requires sacrifices. It's as true in football as it is in software engineering :-)

Plus I'm sure reasonable teams just leave you alone if you do your job well and your setup doesn't intrude on what everyone else is doing.

> That's fine, but being a part of a team sometimes requires sacrifices. It's as true in football as it is in software engineering :-)

It's only fine if this provides something to the team which you could not provide otherwise and in my experience this is not the case usually.

For my day job I mostly write Go. There are tons of great linters you can use with golangci-lint e.g. which is easy to integrate into Vim. I wouldn't see any benefit of using Jetbrains here.. maybe it is true for other languages that don't have good community linters but I think there are not many of these..

I was about to say that. I used to work with python/django and pycharm really does a lot of heavy lifting on the autocomplete/linting part. It knows django and would autocomplete even django's ORM params (which are quite dynamic).

Now I moved to Go, and that is not needed anymore. Most thing are already bultin or can easely be extended (like with golangci-lint). It's static typed with simple OO model which makes things a lot easier. Since then I've been working neovim and I don't feel I miss anythig from full-featured IDE.

Many languages have linters and formatters.

That is what you should use. You can't run Intellij IDEs on CI to validate the pull request.

That said, I do appreciate the powerful code analysis provided by Jetbrains IDEs.

That's the problem Qodana is trying to solve: https://www.jetbrains.com/qodana/

I came across LunarVim not long ago and it helped me go from just using neovim for quick edits and editor keybindings to going down the path of fully using neovim.

I still use IntelliJ for Java, but for everything else neovim is working well. I still have VSCode for a fall back.

Speed definitely depends on use cases. I switched from Vim to Emacs because Vim's syntax highlighting in LaTeX files was so slow it lagged behind my typing (and I am not a fast typist!). This is a well-known problem in Vim and the manual even has a section about it (see :help tex-slow). Emacs was perfectly snappy for LaTeX and I didn't want to use one editor for LaTeX and another for everything else, so I just switched to Emacs for everything.

Treesitter?

I'm not sure what you mean. If you are asking whether either Vim or Emacs use treesitter for syntax higlighting of LaTeX files, the answer is no at least not by default.

> That’s why I am currently trying to get back to using Emacs.

I just wish that people write such posts six months after they have made the switch.

The author has only started. He only has stuff set up and checked speed. He hasn’t yet become as efficient as he was with JetBrains.

He might never become that, and after 20-30 days, he might throw in the towel and go back to JB.

_Being too bullish too soon_ is one of the serious maladies of the present personal-brand/influencer culture.

I switched three years ago and I'm happy with emacs still. I don't find I miss anything jetbrains used to offer me. I might feel different if I spent a lot of time profiling, the one area where an IDE generally has a leg up - but IME the profiling experience in anything that isn't visual studio is bad anyway.

Well, the author says "trying to get back" (emphasis mine), which makes me think that there is some prior experience, it's not "has only started." The article also says:

  > Over a couple of years, I have managed to configure Emacs with most basic modern shortcuts that work in most other applications post the 1990’s (small things like Cmd+S to save, Ctrl+Tab to switch buffers etc.)

which, on the other hand, sounds a bit weird to me. It states that there are years of experience with Emacs, but it wouldn't take years to configure small things like Ctrl+Tab. These are things people use very frequently, so I would imagine one would configure it within the first month, or even the first week, of using Emacs to reduce friction.

I've never understood why developers look to be _tied_ to a single IDE/editor. I also don't get the obsession that some of us have with our IDEs.

What's with the "I am moving to editor X...". You don't have to give up one editor to use another. You can use whichever may be convenient for a given situation.

I use several editors/IDEs based on whatever the language/ecosystem/task at hand is.

Quickly editing a config file? I just use a barebones vim or Sublime Text.

Writing some quick Python/Rust code, I use nvim with plugins.

Writing some SQL: I spin up DBeaver.

When I want to do extensive refactoring or step debugging in Java/Rust/Python: I open a Jetbrains flavour: Jetbrains vanilla/PyCharm/CLion.

IDE at work containing a mix of JS+TS frontends and Go+Python+Rust services: VSCode (it's a nice general purpose workhorse).

I guess the secret sauce to all this is that I have vim shortcuts configured everywhere, so the transitions are easy.

I don't see a reason to be monogamous to one IDE/editor :)

> I don't see a reason to be monogamous to one IDE/editor :)

Years of muscle memory.

Today you can usually customize everything anyway. And if you just want the default setup from another editor there's probably a plugin for that. I remember when moving from Eclipse to IntelliJ a long time ago I brought some of the most commonly used shortcuts into IntelliJ. I then later moved those with me to VSCode and still use them today, took me a maximum of 30 min to configure ONCE so I really don't understand the author's reluctance to configure that in a new IDE.

Nah, when I tried to switch from NetBeans to IntelliJ, there were too many things that just couldn’t be set up the way I was used to operating NetBeans, from window/panel handling to keyboard navigation and code-template expansion. I would have had to write a number of plugins myself.

Yes.

Why do you need to tie your whole self to one IDE/editor?

I use VS Code when writing IoT code, or trying a new language/framework.

I use vim for regular editing.

And I use Jupyter Notebook for all my Deep Learning work.

I don't understand why I need to tie myself to one.

I am also open to trying a newer IDE/editor if that will add any value.

I also find intellij idea (and friends) too heavy. I am using it only when developing java or kotlin because the experience is much better than anything else, despite the slowness.

For anything else (python, js, elixir) I use VSCode with a careful selection of plugins. It works very nice even on my Thinkpad T420.

I agree with the people that said that if you install a lot of plugins (lsp etc) on a bare bones editor it will feel very slow; I had exactly this experience using vim on Windows: Using it as a text editor with only a few plugins (fzf etc) was great but when I started using is more like an IDE the experience wasn't that good anymore resulting in choosing VSCode instead.

> For anything else (python, js, elixir) I use VSCode with a careful selection of plugins.

I find JetBrains IDEs to be significantly better at Python and JS/TS (they do have dedicated IDEs for them after all).

I wish Elixir support wasn't just one guy from Jetbrains working on it in spare time though...

> I wish Elixir support wasn't just one guy from Jetbrains working on it in spare time though...

Better that than the travesty they did to the intellij-hcl plugin, where they .. hired? in-housed? I don't even know what they did to that plugin except completely and utterly broke it and made updates to it go into this weird black hole

I thought the title was a joke, until I remembered a second later Emacs is now perceived as lightweight. The same Emacs was that belittled for its insane memory usage, typically megabytes of memory.

I must be an old-timer now.

The title also mentions IDEs. Haven't things termed "IDEs" always been heavier than Emacs, even back then?

Eight Megabytes And Constantly Swapping!

I remember when I was a kid, I wanted to start coding so naturally most places mentioned Visual Studio.

I installed it in the hopes to begin something new and challenging.

Every time I open Visual Studio, it took an average of 18 minutes (yes, I timed it), and it was using my full 2 gigs of ram that I had at that time, so the typing experience was even worse.

I wish I was more persistent with the idea of start coding, but a heavy IDE was one of the causes my curiosity was killed.

Since that day I have kind of a resentment against big IDEs like the ones from Jetbrains and VS, although my PC doesn't struggle at all with them nowadays.

I mostly use VIM and it's enough for me.

Submitted a bug report regarding poor performance like 2 years ago and they are still "looking" into it. I guess the shiny look has priority over performance for them.

https://youtrack.jetbrains.com/issue/IDEA-270042/High-CPU-us...

They definitely don't seem to care about performance or bugs very much, but it should be noted that the latest version starts up much faster even from cold storage. I used to look at the splash screen for ~8-10 seconds, but not anymore. It was the first significant performance improvement in a very long time.

Other than that, I agree with you. In addition to well-known performance issues and longstanding bugs, I'm also still waiting for features like full Wayland support that was promised by the end of 2020. I mean, I understand it's not on their highest priority, but why promise things you're not actively working on?

I'd suspect that it is a combination of the following:

a) a lot of existing code that needs to be untangled (e.g. moving various tasks to not depend on indices);

b) figuring out how to avoid unnecessary re-indexing (e.g. the downoadable index caches for things like Java files);

c) having to define a migration path to spread out breaking changes to give plugins enough time to adapt.

IIUC, some of the performance work with the latest version is due to parallelizing the various background processes, which uses coroutines, so you could add "implementing language, library, and tooling support to Kotlin/Java" to that list.

Full Wayland support depends on OpenJDK. It was supposed to ship in 2020, but that's Java for you...

> On my top-of-the-line Mac M1 with 64GB of RAM and 10 CPU cores, everything feels lightweight and smooth [...] But when I am at home and want to work on a hobby project, I prefer to use my less powerful laptops [...] after just an hour or so writing code and running tests using IntelliJ, the laptop becomes unusably hot. The fans get louder and louder until it’s really annoying.

To add my anecdotal evidence: I have a relatively new Dell Core i7 laptop with "only" 16 GB of RAM, and while using IntelliJ IDEs "normally" (i.e. not while it's updating its cache), the CPU usage rarely goes above 5%. So the impression that you need top of the line hardware for running IntelliJ products that the blog post is giving is a bit exaggerated...

There could be some kind of limitation on Apple's chips, there are complaints across the Internet of IntelliJ being slow on Mac despite the power of the M-series SoCs. It could be that there are optimisations to be made in their JVM for generating ARM code.

Disabling plugins helps a lot, though. On install you'll get a screen that let's you select tons of features that had me going "gimme gimme gimme" but in hindsight I've never used 90% of them. For example, Android support is a major plugin I've never used with Idea because Android Studio exists and seems to integrate much better. Disabling that cut down startup time by a noticeable amount when I last culled my install.

My experience with tricked out command line editors has been that they start out blazing fast but as you add more and more features (syntax highlighting, linting, etc.) they become slower than your average IDE. They're still responsive when they're not doing anything, but sometimes they just need a few seconds to think, breaking up my work flow.

Another issue that I've seen some people run into is that IntelliJ will index all your files. If you have some kind of process that slows down your computer when you're opening tons of tiny files (say, an antivirus program or a project stored in a hard drive) that can instantly kill your work flow. The only alternative seems to be to postpone loading all the files until you start searching (which VS Code seems to do) but then you're just moving the problem around, not really fixing it.

It's what I get for using a text editor for an IDE, I suppose. My experience with Jetbrains tools is that they're a lot more powerful than most of the competition at the cost of some minor input latency during heavy operations such as indexing.

I am using a seven year old ThinkPad T550 with 16MB and onboard graphics, because I know that if it runs fast on my machine, it runs fast almost everywhere else. IntelliJ is very usable with that configuration, except the terminal (as I wrote in another comment).

  As much as it hurts me to say this, as a fan of JetBrains and its tools, IntelliJ just seems to have become too heavy to run properly on a laptop that’s not at the very higher end of laptops in the early 2020’s.

They advised you to turn off/uninstall plugins, which I did as well. I disabled most of the plugins, even the ones that get shipped by default. For me it improved the performance a lot.

But imho you just need a more powerful computer :). You are obviously missing the features from IntelliJ :).

I thought I did this as well, but I went to check my plugins after reading this comment and I just disabled at least 30 plugins. Thanks !

> But imho you just need a more powerful computer :)

Or maybe we need to stop tolerating performance creep and resource bloat?

Precisely. This pervasive attitude of 'duh, just upgrade your hardware' comes across as elitist, and is very toxic. Not everyone can afford to drop several thousand $ every few years just to maintain a tolerable development environment. Software bloat is ruining the world, it's a significant contributor to making people more jaded about technology and making the future seem depressing and lame.

I'm on your side, but there is not much you can do to convince Jetbrains to make IntelliJ more performant. They are adding more features with every release. You can expect IntelliJ to become slower and slower if you don't upgrade your hardware.

As a user your choice is buying new hardware, or not using IntelliJ. Paulo Renato de Athaydes decided to do the latter :). However, he states that he's missing the features of IntelliJ :). That's why I would buy a more potent computer (or one that has more fans and able to cool down good enough).

That ship has sailed long ago.

These days, Windows Calculator takes over 20 MB to run, despite not significantly changing in functionality since Windows 3.11.

How did we get here?

> "despite not significantly changing in functionality since Windows 3.11."

Here you can run Win 3.1 in a VM in your browser with a click: https://copy.sh/v86/?profile=windows31 and Calculator is in accessories. Make sure to put it in View -> Scientific mode for a full comparison.

Now launch Windows 10 Calculator, you'll see that it is resizable, Win 3.1 calulator can only be minimised. Win 10 shows Unicode characters like Pi, square root, superscript exponentials, Win 3.1 shows them as "x^y" and the letters "PI".

Win 3.1 has a memory. Win 10 has a history log of calculations done, a scrollable editable copyable history and clicking on the entries brings them back to do again.

Win 3.1 has a bug where (2.01 - 2 == 0), Win 10 has that fixed.

Win 3.1 has normal and scientific mode, Win 10 has normal, scientific, date calculation, multiple unit converters, equation graphing with customisable theme, zoomable scrollable live updating high quality, themeable graph.

Win 10 integrates with the Windows contacts in some way to let you share graphed equations with other people. Currency conversion pulls currencies and live rates from the internet.

Win 10 has Programmer mode which does base conversion, logic gates, bit shifting, bitwise number representation with click-to-toggle-bits for entry and viewing.

Win 3.1 calculator is a binary blob, Win 10 calculator is open source MIT licensed on GitHub https://github.com/Microsoft/calculator

Intellij is using those resources to provide very helpful features.

And they do introduce performance improvements - e.g., downloading pre-existing indexes instead of having to index your entire JDK and Maven repo.

https://www.jetbrains.com/help/idea/shared-indexes.html#shar...

Even with a middle of the line laptop from 2017, IntelliJ is not that bad.

Disable extra plugins, do not hesitate to mark directories as 'excluded' if you don't need them to pop up in search (especially build directories), and be patient during the 5-10 minutes indexing when you switch to a new project (which should not happen often) is more than enough to get very good perfs.

IntelliJ ran great on my MacBook from 2015...

Did you try the last step, for maximum performance? Uninstall IntelliJ? /s

> running the community edition of Jetbrains’ IntelliJ IDEA

...

> As much as it hurts me to say this, as a fan of JetBrains and its tools, IntelliJ just seems to have become too heavy to run properly on a laptop that’s not at the very higher end of laptops in the early 2020’s.

IntelliJ does what I want, but only barely. The autocompletion gets it wrong as much as it gets it right and it is a performance hog.

I can deal with that.

The problem for me was JetBrains' privacy policy[0]. It is loosely-worded enough to forbid them practically nothing, and I find that especially appalling in a so-called "community edition".

So I began searching for alternatives. Emacs may serve for OP but I always forget how to exit it so I wanted something with a clickable "close" button in the top right.

I am getting a good initial impression from Codelite[1]. I'm sure Codelite doesn't do everything IntelliJ's IDEs do, but it has the functionality I use and it is a breath of fresh air after waiting for IDEA and the like to catch their breath during text editing.

[0] https://www.jetbrains.com/legal/docs/privacy/third-parties/

[1] https://codelite.org/

> The problem for me was JetBrains' privacy policy[0]. It is loosely-worded enough to forbid them practically nothing, and I find that especially appalling in a so-called "community edition".

What, specifically? Because I can see they are bound by the GDPR and it seems clear to me:

> If you install on-premises products such as IDEs or .NET & Visual Studio Tools, these products are located on your hardware. JetBrains does not provide hosting for these products and does not have access to any of your data processed with these tools, unless you actively decide to share this data with JetBrains.

> I wanted something with a clickable "close" button in the top right.

c'on! Last time I checked (2 seconds ago), Emacs' GUI has a "close" button in the top right. And a "File" menu at the top left with a "Quit" entry, that teaches you the shortcut (C-x C-c).

Emacs in the terminal (emacs -nw) doesn't have the top right button but still has the menu. We can't click it by default though. Use: F10, or M-x menu-bar-open, or M-x xterm-mouse-mode and click on it. https://www.gnu.org/software/emacs/manual/html_node/emacs/Te...

Menu bars are the most amazing GUI paradigm ever invented and whenever I see an Emacs "distribution" which disables the menu bar it kind of feels to me like they would say things like "fire? We don't like that," or "the wheel? Not really a fan of that."

> Emacs may serve for OP but I always forget how to exit it so I wanted something with a clickable "close" button in the top right.

That's the cool part, you don't!

Jokes aside:

- Every emacs install i've ever done had the familiar X at the top right to close it. How did you install?

- Related to the joke, running emacs as a server is quite nice

While lightweightness is often an important factor considered in choosing text editors, their hackability and the fun associated with it can be so rewarding (if you're into it of course).

Sure, elisp may take a bit of time to get used to but writing short snippets can often bring delight, tailored to your needs.

A couple of years ago, I wrote a smartish Swift yasnippet (https://xenodium.com/emacs-generate-a-swift-initializer). A few days ago, I revisted and made it smarter (https://xenodium.com/emacs-generate-a-swift-initializer). Lately, I've made lots of command-line utilities easily accessible with a small package I wrote (https://xenodium.com/seamless-command-line-utils). You can accomplish quite a bit with very little code. Here's another usage integrating with macOS (https://xenodium.com/emacs-reveal-in-finder-dwim-style). You can also goof around a little and create a welcome screen (https://xenodium.com/emacs-a-welcoming-experiment). Perhaps you want to blur the lines between your editor and your shell (https://xenodium.com/yasnippet-in-emacs-eshell). There are lots of packages available that do the heavy lifting, like multiple cursors (https://xenodium.com/inserting-numbers-with-emacs-multiple-c...).

An all-time favorite of mine is the Emacs Rocks multiple cursors episode (https://emacsrocks.com/e13.html). Well worth the watch to the very end. He's just having so much fun.

Haha! I didn't recognize your user name or domain name and when you mentioned seamless access to command-line tools I almost recommended Álvaro Ramírez's dwim-shell-commands package to you. Glad I clicked the link first. ;)

Oh yay! Nice to hear you find dwim-shell-command useful. Thank you.

> Jetbrains is working on Fleet, a new, lighter editor from JetBrains, and while it seems very promising (it’s quite pretty, well thought out, modern)

Heh, these days I'd consider a program advertising a "modern" UI/UX to be a bug, not a feature. Current trends of making everything flat and hiding functionality sucks.

Kiss your productivity goodbye. Emacs has lots of half-baked features that you'll be tempted to fix with its LISP dialect. It's so much fun to tinker that you'll wonder where your day went.

The $20 I spend every month on my JetBrains subscription is easily worth it. I can depend on my IDE to be working well and not waste time on fixing buggy features. The JetBrains people are also highly responsive to bug reports.

True - nowadays, `Eight Megabytes Always Continuous Swapping` is a feature, not a bug...

I love emacs. I don't use an IDE unless I'm forced to, mainly because I simply don't use the features most IDEs offer, and have considered them bloated nightmares since the first time I used one. Emacs has everything you need, and is fast enough, with few exceptions. Same for vi(m).

I recently started using intelliJ's datagrip. For some reason, it stores its metadata in xml files, 150Mb or so per database. One postgres DB cluster it actually refuses to index unless I select only some of the DBs in it. Mind you, these databases are not particularly big, e.g. 17GB for the cluster it doesn't want to index.

When it starts up, it loads all this metadata in memory. You feel the laptop being slow for a minute or so. After that, its mostly a good tool. Once in a while, it indexes something and grants you another coffee break.

I keep wondering, why XML? If you build this much metadata, wouldn't it make a lot more sense to store it in a database itself, and only load what you need from it? Say sqlite or h2 or something.

My guess it started relatively small, and more features added over time to the feature, and they never thought changing about the XML part.

Another thing is, XML can be converted to objects and vice-versa relatively easily, so it is a neat serialization format in nature.

Also, parsing XML fast is a solved problem for the most part.

I have worked with relatively big XML files, and when done right, the path is not heavy, at all.

Edit: Oh, Considering this is IntelliJ and Java talks XML natively, this might also played a role in this being XML.

Not complaining about the xml vs json vs yaml vs csv thing. It's more that when you choose XML, you've chosen streaming and reading it completely. There is no way to read it partially and only use the little bit needed.

> ...when you choose XML, you've chosen streaming and reading it completely.

That part is pretty true. I didn't use XML in a case where I didn't need to read it completely and transform to objects, yet.

I'd not choose XML in these cases probably, if I ever encounter such a case.

DataGrip isn't perfect but it's radically changed how I work with SQL. It makes writing queries so incredibly easy, with a god mode autocomplete. JOINs are so easy <3

Does anyone knows of vim or emacs plugins that do similar heavy lifting? Preferably decent at T-SQL

IntelliJ needs a lightweight competitor, if that's possible. As the article points out, it's slow! Drains laptop battery, requires a powerful computer not to have slowdowns etc. (Using PyCharm, mainly with Rust plugin)

Sublime is much lighter, but not as powerful.

Not sure how'd you compete on features without being as heavyweight.

Valid lol. My desktop can keep up, but I think I'm done with IntelliJ on my tablet. It's smoking the short-term battery life, and I imagine it's smoking the long-term as well. Not worth that, or the latency.

> ... apparently, writing code on anything other than top-of-the-line machines is too much to ask for.

You guys are way ahead of me, so I need to learn. E.g., I'm missing the need for "top of the line".

For my Web site startup, I typed in 100,000 lines of text, 24,000 programming language statements, in Microsoft's Visual Basic .NET using an old desktop computer with a processor with a single core with a with a 1.8 GHz clock, Windows XP, SQL Server, calling LINPACK via Microsoft's platform invoke, and the editor KEDIT (with ~100 macros I wrote) with command line commands in ~100 Rexx scripts I wrote.

Once I got past some documentation frustrations, I was thrilled with all of it: I typed in code using KEdit, compiled it using a Rexx script, then used another Rexx script to run it, e.g., to run the Web site locally, i.e., with IP address 10.0.0.177.

I thought that the compiling was fast, nicely fast, really, blindingly fast. For the code to start running and the Web site to be functioning -- again blindingly fast. I was thrilled.

Something went wrong, apparently with the motherboard, and I got an HP laptop with a 2 core processor and a 2.5 GHz clock to use while I plugged together a desktop with an 8 core processor and a 4.0 GHz clock. Then compiling the code and running it were faster than blindingly fast, nearly too fast to get finger off the Enter key.

I've considered moving to Emacs instead of KEdit and to Power Shell instead of Rexx, but so far I've not seen anything like

> ... apparently, writing code on anything other than top-of-the-line machines is too much to ask for.

What am I missing? Maybe I'm missing some big things an IDE (integrated development environment) would do for me?

I've been delayed by collecting data, etc., but am getting back to code writing and running so would like to know what I'm missing?

In simple terms, I see programming as just typing in text and like KEdit, and my macros, for that. Then for the compiling, building, just run the compiler -- it runs right away.

Does KEdit do symbol completion, show you documentation as you type, and perform automated refactoring? Those are the big wins for the heavyweight editors. Especially when working with a verbose language like Java or C#, editor support is very nice. Also, in languages without keyword arguments, seeing the correct order of arguments as you type is very helpful, as well as seeing a docstring to confirm that your unreliable brain picked the right function.

> Does KEdit do symbol completion, show you documentation as you type, and perform automated refactoring?

KEdit is not specific to software development but is for nearly all typing. E.g., I also use it for word processing, reading/writing email, notes on everything, Internet content on finance, BBQ, coconut cream pie, Moo Shu Pork, ....

So, for writing software using KEdit, need some more: It has a good macro language, so can write macros to do some work specific to software.

> symbol completion

Interesting question! I do some of that with command line commands in text console windows. E.g., in walking in the file system directory tree, I have a little Rexx script

     dn 'argument'

where 'argument' is a string, maybe the first few characters of the name of a subdirectory of the current directory. If the completion is ambiguous, then the script writes out a list to pick from.

I just checked the KEdit Help: So, in the case of an ambiguous completion, in a macro can use the command POPUP to create and display such a window and in it have a menu the user can pick from with either mouse or keyboard, and then the selection is returned to the macro. So, then, need the macro to know what the legal completions are: Okay, might get those from the current file being edited. Or maybe the list is in the macro or in a file the macro would read, maybe that file particular to the current directory of if there is no such file then, ... be as fancy as want with a hierarchy of files of the legal completions, one for C code, one for cooking, one for .... Depend on file system caching to make the file reading fast. And have the macro use the KEdit locate command which is really fast. The user's string might be from the start of the keyword, anywhere in the keyword spelling, after some spell checking in the macro, as fancy as want!

> show you documentation as you type

My approach to that was to put tree names of documentation files in the comments in my source code. Then I wrote a little KEdit macro that would, assuming simple syntax, grab the tree name and display the file. If the file type was HTM, then the macro would invoke Firefox to display the HTM file. I have 500+ of those. The file might be just simple text, and then the macro would open the file and have it in the ring (collection) of files KEdit was working with when it ran the macro.

> perform automated refactoring

I'll have to guess what that is: Maybe it is changing some name from, e.g.,

     call_sql

     call_sql001

For things like that, I just use versions of the KEdit command to locate a string. Here the command would be one of

     /call_sql/

     >call_sql>

     l/call_sql/

     all/call_sql/

etc.

Could write a macro, pass as an argument the strings

     call_sql call_sql001

and have a loop for a little dialog that would locate the first argument, thus show the context, permit change or not, and then loop for the next change candidate.

Of course, if the work is really simple, then could just use

     c/call_sql/call_sql001/ * *

for make the change on all the lines and all cases on each line.

In short, KEdit has a lot of good functions and a good macro language.

And for the start of this thread about needing high end processors, I've been using versions of KEdit back to VM/CMS and PC/DOS. So, it's small and fast.

KEdit is a PC version of IBM's XEDIT written in France by some guy on his own time. Once it was on IBM's internal network, it spread to IBM sites around the world quickly. In a word, KEdit is elegant. It is my most heavily used tool.

The KEdit macro language is a version of Rexx, the scripting language developed by an IBM guy Mike Cowlishaw. Early on KEdit macros could be written in Rexx and run on the instance of Rexx that served text window command lines, but eventually some operating system changes blocked that, and the author of KEdit wrote a version of Rexx and included it in KEdit.

Emacs may be a more powerful editor.

Power Shell may be a more powerful way to write scripts.

Refactoring is anything that simplifies the code and prepares it for modification. For example, extracting a function, or a variable; pulling code up to the superclass because it's common or pushing it down to subclasses because it shouldn't be common; etc. Renaming is a part of refactoring but most refactorings involve code motion.

KEdit sounds pretty scriptable, but it seems limited by treating everything as text and not being aware of syntax.

I do most of my work myself in Emacs without much of the "heavyweight" stuff. Nonetheless, for writing Java or exploring a large program, an editor that has already grokked and indexed everything is really useful. As an example, I can point to a name and go to its definition immediately, without running a more generic search. Then I can enumerate its uses and see what the idiomatic use is.

Not trying to convince you to use something else, just giving you an idea why people like these tools.

I do a little with objects but not a lot. Doubt that I ever wanted to refactor some! Yes, some of my code editing, revisions involved code motion, but I don't recall that was a big problem.

> KEdit sounds pretty scriptable, but it seems limited by treating everything as text and not being aware of syntax.

Right. To have KEdit honor syntax, would have to program that in the KEdit macro language. No doubt that is doable, and since the macro language has a lot on string handling quite doable. Doable but for me more work than worthwhile.

KEdit is old but so is Emacs.

> Not trying to convince you to use something else, just giving you an idea why people like these tools.

Thanks, I've been wondering what I'm missing not using Emacs.

For an IDE, once I looked at Microsoft's Visual Studio. Created a project or whatever it was called -- years ago. It created a directory with lots of files. And that was before even "Hello World". I didn't know what all those files were for, didn't want to go to the trouble to find out, and was concerned that if something went wrong I'd have to fix it. I gave up, but here with the start of this thread wondered what value I might be missing from some heavy computing busy trying to make my work easier -- what was it, 12 cores, 64 GB of main memory, gads?

So, for now, stay with KEdit and Rexx.

I could have wasted time evaluating IDEs. Thanks!

I don't use IDEs at all. The features I see that I think "that's nice" are:

* Integrated with the build system (shows lines that fail the build etc.)

* Integrated with the debugger (mark lines to stop at, follow the lines)

* Integrated with a language server (highlighting, style errors, help, "IntelliSense")

* Automated Refactoring (rename variable, function, class, and it's updated everywhere)

* Integrated source control (git, etc.)

* Inline documentation as well as autocomplete.

Things I haven't seen but seem like natural progressions:

* Integrated CI/CD: deploy straight from your IDE, view pipeline outputs

* Production/remote debugging: connect to running processes non-destructively to find memory leaks, etc.

To be honest, you sound perfectly productive without an "IDE". If everyone has a set of tools they are comfortable with I don't see why that isn't as good as a singular IDE. Then again, as I said, I don't use IDEs at all...

I’m still waiting for a rust text editor or ide to emerge and take off. I think that’s going to be ‘the one’. I’ve been trying to go for rust software wherever I can on my new MacBook and it’s always blazingly fast. Alacritty literally loads instantly - makes the terminal experience so much nicer.

In the mean time, I’ve tried out Atom, VSCode, Vim, Emacs and PhpStorm but settled on using Sublime Text and Sublime Merge after watching a senior wizard use them day in day out at my last job. I absolutely love their minimalism: I want as little as possible on the screen to distract me when I’m coding. Atom, VSCode and especially PhpStorm all felt too bloated and cluttered: way too many panels and buttons taking up real estate from the text editor. Focus mode isn’t the solution for me because it’s annoying coming in and out of it all the time when you want to do a file search or look for something in the directory tree or what not. For me, Vim and Emacs were too much of a pain in the arse, both with the endless configuration and research you have to do to get a decent set up and with having to remember all the keyboard shortcuts and look one of them up from a cheat sheet when you inevitably forget. For me, Sublime Text really is the sweet spot between the two worlds.

XEmacs was my IDE when UNIX environments didn't offer anything better, and most likely Emacs nowadays has implemented most of the stuff that XEmacs had going for it over Emacs.

So it was my "IDE" between 1995 - 2005 when working on UNIX, muscle memory is still there and I still remember basic elisp stuff, yet I see no reason to abandon my IDE's, now that they are available everywhere that matters to me.

Emacs people: How well does Emacs manage many files being open in disparate directories? I've often got two dozen files open as I navigate source code of a new codebase, and my current IDE (Jetbrains) does not have a good way of organizing the tabs so that I can quickly find them by module (not filename).

For instance, consider the following open files:

  projectRoot/beatles/foo/bar/alice/bob/charlie/a.c
  projectRoot/beatles/foo/bar/alice/bob/charlie/b.c
  projectRoot/beatles/foo/somethingElse/UI/keyboard/usbSupport.c
  projectRoot/stones/mick.c
  projectRoot/stones/bass/dick.c
  projectRoot/stones/bass/ricky.c

I'd like a single "view" (whatever that may be. In Jetbrains it's a tab bar, in VIM it's an ASCII list) to see all the files, but collected into "groups". So the files in the `projectRoot/beatles/foo/bar/alice/` group are all together, the files in the `projectRoot/beatles/foo/somethingElse/` group are all together, and the files in the `projectRoot/stones/` group are all together. All other files would be in a separate "group" visually.

Notice that each "group" is _not_ a child of a single parent directory. I would define these groups manually - each project only has a handful of groups that I need. This is the feature request for Jetbrains, with each group defined as a Jetbrains "scope":

https://youtrack.jetbrains.com/issue/WI-61955/Tab-bar-row-pe...

Any ideas for how to handle this situation in Emacs would be much appreciated. I've begun using Emacs for org-mode (with Evil) and I'd love to actually develop in Emacs if it has really good groupings of files.

It seems that by default, Emacs wants to treat what it calls “projects” as files having a common root directory:

https://www.gnu.org/software/emacs/manual/html_node/emacs/Pr...

https://www.gnu.org/software/emacs/manual/html_node/emacs/ED...

There are, however, a fairly large number of third-party packages¹² which seem to be for project management, but I have not tried any of them.

1. https://elpa.gnu.org/packages/

2. https://stable.melpa.org/#/?q=project

  > Emacs wants to treat what it calls “projects” as files having a common root directory

Yes, I am using that terminology. I'm not looking for project management, rather, I'm looking for a better listing of open files.

ibuffer sorting by filename?

Also alphapapa has something related...

Ah yes, bufler.el:

> A butler for your buffers. Group buffers into workspaces with programmable rules, and easily switch to and manipulate them.

https://github.com/alphapapa/bufler.el

This looks terrific, thank you! I'll go over it this weekend.

Great! I'm still just using ibuffer, but will reach for Butler as soon as I need custom rules.

Then again, maybe sooner for tab bar support...

It sounds a bit like you want „perspective.el“ (1). It allows you to define „virtual workspaces“ of buffers with individual window layouts. On each virtual desktop the standard buffer list is replaced with a shorter showing only buffers belonging to the current context. I use it every day to keep „code“ buffers separate from my „test“ buffers.

(1) https://github.com/nex3/perspective-el

Thank you very much, I will go over perspective-el this weekend.

I write C++ professionally and primarily edit code using Emacs inside Tmux over ssh, and I've found once you get accustomed to it you can be just as productive without any fancy plugins. E.g. instead of autocomplete, it only takes a couple seconds to split the window, open the other source file in the second pane, jump (by text-based search, if you weren't already there) to where the definition is, highlight the word and copy-paste it back to the first pane. And that way you never have to worry about your tooling randomly breaking in template-heavy code, something no C++ IDE is safe from. No more moments of frustration when the IDE randomly freezes while you're trying to do something important.

Most of the things IDEs provide are unnecessary, and ultimately harm the developer by permitting skill atrophy of one sort or another. My opinion (obviously, and perhaps controversially). There are some exceptions (e.g., because the other tooling is garbage, one might consider Visual Studio "necessary" for building certain applications on Windows), but not many.

If you think lsp-mode is too slow you can simulate „jump to definition“ using old-school „xref“ and „etags“ that comes with your Emacs. It creates a reverse index for you. Then you can put that in your git repo and add it to your .gitignore.

Finally, you can press „M-.“ for jump to definition and return to your buffer pressing „M-,“ — if the name of the function is unique. In practice, that works good enough most of the time.

„etags“ runs so quickly you can call it from a git hook and re-generate the reverse index every time you pull or check out a branch.

It works with all languages. No lsp server required.

Doesn't the language server lisps provide that? (I'm postponing installing and learning to use any for years...)

Yes, language servers provide that feature, too, and all language server clients replace „xref“ with their own implementation. „lsp-mode“ even provide some gui extensions to Emacs so it can display a hover window when there are several possible matches for your definition (e.g. all overridden methods in your inheritance tree). That’s quite cool.

But the disadvantage is you now need to run a static analyzer in the background parsing half of your code base to find definitions. On very large code based this can create slow downs.

Furthermore, finding definitions by means of static analysis cannot always work, especially so in dynamically typed languages or in languages employing generic variables.

> E.g. instead of autocomplete ... split the window, open the other source file in the second pane, jump (by text-based search, if you weren't already there) to where the definition is, highlight the word and copy-paste it back to the first pane.

Just to be clear, are you being serious? I mean this is what I do too when autocomplete doesn't work, but it's very obviously far inferior to actual autocomplete.

> instead of autocomplete, it only takes a couple seconds to split the window, open the other source file in the second pane, jump

It takes less than 0.3 seconds with autocomplete and doesn't force a context switch.

Maybe your method isn't a context switch for you, but it very much is for me.

Also, if you know the source file to open don't you likely know the word making the faster option to just type it?

I can't tell if this is a joke or not, it sound awful. Further it requires already knowing the API, something autocomplete aids in learning.

TBH nowadays I give up learning either emacs and vim, it's just too much time to replicate the experience in Jetbrain editors. I'd just throw in an extra thousand and buy something more powerful, like a 16g m1 macbook pro. Time is precious.

> too much time to replicate the experience in Jetbrain editors

That's not what most emacs or vim users are trying to do?

Or I should say same smoothness? I think experience is a better word.

IntelliJ also has a "Power Save" mode if you want to disable a lot of the background stuff while on battery.

The reality is, with large projects there is a lot of crunching going on in the background. Laptops tend to reduce their processing power when on battery, so a few options are:

- use a dev server! I have a desktop at home I can use - a cheap desktop is much better than a cheap laptop. Or rent an on-demand from the cloud. IntelliJ has nice remote development support.

- plug into the wall

- turn off everything non-essential like plugins

- use emacs/vim!

I love vim as much as anybody but now that I am older I don't have much time to mess around with configurations. I am learning rust and it is great to open up CLion and just get down to business.

Back in Emacs's heyday, it was the editor everyone was complaining about for being too bloated and slow ("Eight Megs And Constantly Swapping").

Today, Emacs is a great retro video game, but you will be kneecapped if relying on it for serious programming work. For pay or otherwise. And if you're like me, you'll become mired in it and everything else will seem as a pebble in the shoe. Don't be like me.

Using a modern IDE, or IDE-like editor, is a critical developer skill because that's where all the tooling and attention is. Focus on that and don't attempt to cosplay as an old-school wizard by faffing about with things like Emacs.

> Today, Emacs is a great retro video game, but you will be kneecapped if relying on it for serious programming work.

I haven't felt like this was true since lsp support matured.

Plus there are big benefits to having the same editor, autocompletion, etc while coding that I already use daily with org-roam.

LSP helps, but even with it Emacs is falling behind. Language hackers support Visual Studio Code first these days, with extensions that go beyond LSP.

> Language hackers support Visual Studio Code first these days, with extensions that go beyond LSP.

Can you give me an example of one?

Julia's VSCode extension provides linting, debugging, and live interactive development features that go beyond the language server:

https://www.julia-vscode.org/

I don't agree with this at all. I think a modern, fully-tooled up Emacs is significantly more capable overall than e.g. VSCode. There's more configuration involved and Emacs lacks some features, but that goes both ways.

Compared to my non-Emacs using colleagues I'm significantly faster at manipulating code. I don't think that's because I'm smarter or intrinsically faster (they're mostly younger, for a start). Emacs is just a lot more efficient once you've learnt all the tricks and built up a platform that suits your preferences.

What really irritates me about IntelliJ is the terminal (on Windows). It is slow as molasses (can be down to two characters per second), and sometimes typing occurs not at the prompt, but a few lines above. How can something like a terminal be that broken? And there were a ton of issue reports in the past, so I don't even bother to write another issue report.

I finally found that disabling "Typeahead" in Advanced Settings seems to help quite a bit so I will stick with IntelliJ, because I quite like it aside from the terminal. But I was ready to jump ship a short while ago (because of the performance of the terminal, can you even imagine?).

I absolutely love Kotlin (and I do like the folks behind Jetbrains), so I'm kinda de facto locked onto IntelliJ but damn that post is right in the feels.

Yesterday, I had to let go of my 4K screen and go back to working on the laptop screen of my 1 year old M1 because of some issue that is open for 7 years (https://twitter.com/jlengrand/status/1601246555066859520).

Back then, I upgraded my laptop because the indexing of semi-large projects was making me go bonkers.

Sometimes, it does feel like my DevEx is getting worse over time. Not better

I don't know the impact on battery, but there's a Power Save mode in Jetbrains IDEs that makes the IDE slightly snappier, when you just want to read some code or do one or two modifications.

I've got an Emacs window open on the top and PyCharm on the bottom of the screen. The main story in the IDE for me is first class debugger, visual refactoring tools and luxury level toolchain integration. The main story in Emacs is org-mode, runs almost anywhere, plus, great text editing features (try running a macro in the IDE... sometimes I can actually type faster... all on a 2022 i7 with 32GB of RAM). I think we're dealing with the same problem we do with all development tools: functionality vs. performance.

The OP would probably find that any IDE works just fine on the baseline MacBook Air from the Apple Silicon era. But anything older than that is probably going to have problems.

As an nvim user – the IntelliJ feels a lot more responsive than VScode, and the whole thing when configured carefully is a breeze compared to everything else i used. It's pane management is so good, and it fits seamlessly inside a vanilla terminal. It's keyboard-first support is, with no doubts, the best-in-class. I can navigate it so quickly at this point any other IDE feels like an aimless turtling

Checkout also https://github.com/AstroNvim/AstroNvim

Yes. I have to build small, permacomputing-inspired stuff, so I resort to (neo)vim wherever possible.

The complexity of the toolchain tends to sip into the result over time.

Conway's law.

I've used Emacs for years now.

What I like about it is how little I have to use the mouse. Actually, I don't have to use the mouse at all, but sometimes I'm just lazy. It's all keyboard, baby. :)

Once you get used to the keybindings you can keep a steady flow and concentrate on your work, in contrast to pretty much all modern IDEs which are mouse driven.

I noticed that I focussed more when my Mac terminal was full screen and only using vi to learn rust with almost no plugins. It forced me to reason about the borrow checker before cargo build. I still use vscode for debugging once in a while, but I think it improved my understanding of the language and also prevented me from getting distracted.

I'd be happier if:

1) Some random mode couldn't kill M-% search and replace. Something somewhere does it in some of my installs.

2) Magit was reliable on MacOS. On one machine, it's fine. On another, I have some random issue with emacs server and therefore I'm not able to commit, or do anything where I can edit a message buffer.

I abandoned JetBrains a long time ago.. too bad, because they always have really good language/framework/platform tooling, but I just can’t stand the IDE. I don’t see them just creating a language backend for VSCode.

> (funny, because at the time it was created it was considered a heavyweight… how things change)

No kidding, but I remember in the early days, when people complained, RMS said something like "the hardware will catch up".

Seems he was right :)

I highly recommend the Geany IDE as well, it's very simple and lightweight, but still has conveniences like an integrated terminal if you like, automatic state saving, etc. Best IDE in my humble opinion!

My "least powerful" laptop that I still use for development is ASUS TUF A15. With Ryzen 7 4800H CPU. 8 Cores 16 threads. I bought it recently dirt cheap for $799 Canadian (translates to $586US approximately). Stuffed it with 64GB RAM (I had it lying around but it is cheap anyways).

I run CLion from JetBrains on it for my C++ development. When doing full rebuild of the project and libs (all cores at 100%) the fan comes on but not really loud and goes back to sleep for the rest of the development. Building itself is really fast.

Not sure why you have such poor experience. Maybe those thin laptops can't really handle CPU loads without overheating.

We still have many Thinkpad T490 with Intel Core i7 and 40GB Ram. They overheat and throttle gpu and cpu to the point you can't work anymore. Even the mouse comes to a halt. The fan barely spins up. Absolutely rubbish.

Then we have Thinkpad P15v2 Gen2, also with Core i7, the moment you fire up your compiler, the fans spin up immediately (also very loud). No throttling, you can compile all day.

At home I have a Thinkpad Ryzen laptop, no fan noise, no throttling, full power. It's just a different kind.

I guess the recipe is - do your homework and do not buy crap but that is what many corporations do for their employees. Their laptops cost way more than the one I mentioned and are still slow.

T470 was fine :). $Company thought that a "T490 must be better and good enough" :). In fact, if you cool down a T490 good enough, it _is_ faster than a T470, but in the end the T490 is useless for a developer that needs processing power.

That's some crazy powerful hardware, and would be a significant upgrade for most people.

My main and only laptop (apart from some ancient ones) has a quadcore i5-8350U and 8GB RAM. (I kind of want to upgrade its RAM though)

I also have a PC, that I upgraded to a Ryzen 7 5800 and 32GB RAM recently, but a few months ago it was an i7-4790K with 8GB RAM.

Sure, 8GB RAM is quite little, but it's still within the mainstream. In laptops quad-core CPUs also only became mainstream in the last few years, let alone more than that.

FWIW, I don't have any real performance issues with Jetbrains IDEs on either of my machines, but I don't use them much either as I don't like the convoluted user interface.

>"That's some crazy powerful hardware, and would be a significant upgrade for most people."

I have my own company. Cost of this laptop goes as a business expense and is peanuts comparatively to revenue.

>"Sure, 8GB RAM is quite little, but it's still within the mainstream."

I've never cared about mainstream. Not in the industry and neither in private life. I do what works for me / my company and could not care less about what others do.

Congratulations? I'm not saying you need to care or whatever, I'm just saying you shouldn't dismiss people who do need to care for whatever reason.

Great that you always have access to a computer with 64+ GB RAM, but not everyone is quite so lucky.

Sorry for sounding cocky. I was responding to a "mainstream" part assuming you meant it as an usual industry norm that had nothing to do with what people can usually afford.

I developed products for many orgs and had interacted with many of their programmers and from my experience they all had very decent salaries and absolutely shitty computers. Their orgs could definitely "splurge" for what I spent on that laptop without noticing much. As a matter of fact they spent more on their crappy hardware than I spent on mine due to their purchasing policies. From this point of view yes: I do not give a flying fuck about the norm.

If it is about individual trying to make ends meet I have nothing but respect.

Something I recently missed emacs for, was being able to use it to transparent edit a file over SSH.

I couldn't find an easy way to do that with IntelliJ/phpstorm.

Slightly off topic: any reviews of Zed or Helix here?

How does it compare?

Zed! That's a blast from the distant past! I enjoyed this 1980 paper about its development: https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.43801001...

EDIT: I just saw in my own comment history that I knew (but forgot) there is a more recent Zed text editor which is probably the one you meant.

A couple of months ago I switched from Neovim with a carefully crafted config file to Helix with zero config. I haven't looked back.

As far a performance, well, Helix + Alacritty is the fastest thing I know of. Snappy AF. You're still at the mercy of whatever language server might be grinding away, but at least it doesn't block the UI in any way. Every other component (tree-sitter, ropey) is performance optimized by Rust nerds who love that sort of thing.

Helix is awesome. But the plugin system is not there yet, so it is limited to its core features. There are no extensions so you only get a very good modal editor with very well made core features based on its LSP and Treesitter integration.

The only reason I don't want to make the switch is the missing (but WIP) support for multi LSP which is essential for frontend stuff (e.g. tailwind with React or just basic JSX support compared to VS Code). Snippets are WIP as well, but I could live with a workaround like pasting them from somewhere else.

I think the cycle repeats itself, there used to be bloat-wares like Eclipse (IntelliFuck) that programmers would swear by. Then came Sublime and people had a revelation about how light and fast an IDE can and should be. Recently there has been another wave of hipster programmers swearing by bloat-wares like VSCode.

Now people have to rediscover Emacs from 47 years ago.

It's really funny that people see Emacs as an alternative to bloatware.

For most of its history, Emacs has been the very definition of bloatware.

What do you mean, doesn't every IDE need its own Infocom-esque text adventure, psychoanalyst, IRC client, web browser, Morse code translator, ASCII art drawing tools, and Tetris implementation? Of course all that bloat is an acceptable price to pay for the best editor available.

Sorry but Sublime isn't an IDE. It's a text editor. Emacs and Vim too.

It all depends at which level you configure them in the end.

vanilla emacs/vim with default config are just editors, but they can be configured to have most if not all the functionnalities of an ide.

I agree but people often compare vanilla text editors with fully-featured IDEs which doesn't make sense.

Anything that does syntax highlighting, jumps to definition and allows you to install additional packages/functionality is an IDE and everything else that you call an IDE is actually bloatware (see, I can do that too.)

No, I don't need to freaking have a goddamn FTP and SSH client built into the tool that I so heavily rely on every day just because there is a use case for it in someone's brain that is orthogonal to the vast majority of its users'.

Also fuck the evil that is Codespaces.

> and inserting custom snippets for things like System.out.println and public static void main

YASnippet!

> The shortcuts are just unergonomic in my opinion

Extensions -> type "emacs" -> done

I really hate this articles that scream "look I'm so old school I use vim/emacs" while emacs is a single threaded nightmare that will work worse than any IDE if you will try to configure it to make it usable for actual every day work.

Many, many people use emacs and vim for everyday coding. You sound confident, but you'd also be wrong for a large swath of programmers.

My space suit is too heavy so I moved into my bathing suit.

Well, the bathing suit comes with rockets and you can bathe in lava though.

And a kitchen sink. Can't forget the kitchen sink.

You might need to jerry rig the life support system though.

Cooking is too complicated so I'm back to hunting and gathering.

Ordering takeout is too complicated, and they always botch my special orders, so I’m remodeling my kitchen. Again.

1. Disable unused plugins

2. Exclude folders from indexing

3. Tune the JVM

It is less work than tuning emacs.

I use vim inside a VS Code terminal. Best of both worlds.

I've heard of a vim extension/mod for VS Code but haven't had the time to dig into it.

You could use vim inside a regular terminal for the same effect, with a notable exception of sending all of your keypresses to Microsoft.

Definitely not the same effect. The vscode application is much nicer than a terminal, has lot of plugins that I'm not sure exist for vim. And you can disable telemetry. And it's much faster to learn

I feel like Vim has more plugins than VSCode

Nothing wrong with your setup if you like it, but I'm very curious what features you are missing in vim. Can you give any examples?

The learning curve mostly. And most things you need are there out of the box, or very easy to install. Also plugins like remote ssh. Overall it just works without too much effort.

Remote ssh is built into vim. I think it's formally a plugin, but it's installed by default.

Of course, if you don't use too many plugins, vim is also designed so you can run it remotely. I use this sometimes to have a long-time running vim session on a remote server, using tmux or screen to reattach when I log in.

Ironically I find using a terminal inside VSCode horrendous. And since most times I need to open 2-3 of them, I have a much better experience with one terminal outside of it, and tmux.

And if you haven't tried it, use tmux.

It is the geeky tool that unlike vim/emacs you can learn in 60 seconds and immediately adds value. Whereas vim/emacs take longer to learn and get a payoff - I never managed to get to that part of the curve.

Add another 5 minutes to set up a tmux script for your development workflow!

I use screen which I prefer to tmux

I used to use byobu, but the Python dependency eventually swore me off of it

Reply on news.ycombinator.com