My IDE is too heavy so I moved to Emacs (2024)

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

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.

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.

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.

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.

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.

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?

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.

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.

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.

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 sh*tty 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.

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/emacshttps://github.com/manateelazycat/lsp-bridge

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.

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 :(

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?

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.

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

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

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.

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

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

Tech sure moves fast...

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!

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.

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

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

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

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.

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

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

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.

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

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?

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.

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.

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

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.

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.

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"

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

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

Same here except that each year it seems likeI 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.

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

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.

Also see:

https://www.lunarvim.org/

https://nvchad.com/

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.

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.

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

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.

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.

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.

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

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

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

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

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

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

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

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.

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

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

> 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

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

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.

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

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.

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

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

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

> 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 

to

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

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

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

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

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.

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?

> too much time to replicate the experience in Jetbrain editors

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

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.

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.

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

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

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

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

> (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 :)

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.

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 co*cky. 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 sh*tty 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 f*ck about the norm.

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

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.

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?

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.

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.

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 (Intellif*ck) 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.

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.

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 f*ck 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.

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.

1. Disable unused plugins

2. Exclude folders from indexing

3. Tune the JVM

It is less work than tuning emacs.

My employer pays me to work 37.5 hours a week. An excessive amount of hours beyond that would raise potential legal issues, as there are limits on how much overtime is allowed.

And yes, people do things for fun, too, not just for money.

> You should not be programming outside of that

I shouldn't do what I like because what? Because bowsamic doesn't like it?

I think I speak for essentially everyone here when I say, "fk this guy's boss". Old mate here in this thread slacks off or 2 days, his boss is already very respectfully thinking of firing him.

It's not 1920. The modern middle manager has more invested in his fantasy football league than his direct reports -- and by some magnitude. Grow up.

Many people like to work on hobby projects, and hobby is usually done at home or somewhere else than work.

It's also not recommended working on personal stuff with work's hardware and means, you risk losing your hobby projects to your company.

And during work time, you are supposed to work on things the company told you to do, not personal stuff. If you are planning to do extra hours for that, why should it matter where you do it?

Your comment probably seems non intuitive to many of us for all these reasons.

https://justforfunnoreally.dev

I did not understand this viewpoint until I started to program for a living.

So, don't worry about the downvotes. They will understand someday.

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.

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!