What does eMacs have to offer a rider or other jetbrains ide coder? Somebody who is used to some really handy refactoring, autocomplete, and auto formatting tools for very large code bases, Eg, like an unreal engine game project (which even visual studio can’t really keep up with)
Practically speaking, probably nothing that would make up for the loss in functionality. The main practical reasons might be slightly better git support (magit) and the ability to run in a remote terminal -- as well as being generally more lightweight. But for that alone, vim might be a better choice.
Conceptually speaking, it remains (despite various flaws and warts) one of very, very few well thought out pieces of non-trivial software. For decades, emacs was pretty much the only program with a search function that didn't suck. Emacs is still the only program I know pf with a decent, branching, undo system and proper, non-alzheimered copy-and-paste. Vim has branching undo system, and a clipboard that can hold more than one item, but both work poorly (e.g. in emacs it's ergonomic to cycle through clipboard history or pull a clipboard item by textual content, in vim it really isn't). Emacs is also remains far more deeply extensible and self documenting than anything else I can think of.
Quick plug for org mode. As is said in my comment’s parent, Emacs is not the editor for that kind of project. I picked it up solely for org mode (it WILL enhance your life) and now I find myself using it for simple/low stress coding projects in and out of work because I find the motion/navigation/editing satisfying.
I'm more of a vim user that occasionally dabbles in emacs (mostly for lisp).
But... everything.
> Somebody who is used to some really handy refactoring, autocomplete, and auto formatting tools
Those aren't really differentiators anymore. They're available everywhere (even vim/emacs). LSPs have made the choice of thing for editing pretty irrelevant.
There's also the debugger adapter protocol, which has worked surprisingly well. Though I do still miss intellij's conditional breakpoints occasionally, it's rare that that's necessary, but they're surprisingly useful when you need them.
So, with emacs, you'd have everything you listed, and everything else you hear people talk about with emacs. Emacs will pretty much do anything. At the cost of higher initial set up effort, and config maintenance.
For languages and environments where there is a competitive language service, yes.
So far I've only seen rust-analyzer get even close to intellij (for directly supported languages). Every other one has been mediocre at best or downright awful.
Even the worst is generally better than no support and flaky or non-existent syntax highlighting though - language services have massively improved the breadth of language support in [random editor X] and I'm totally sold on them as a concept.
That's fair, I haven't experimented with everything the jetbrains suite supports.
I've had good luck with javascript's, python's and go's language servers specifically. I'd think maybe C#'s would be rough, but microsoft is behind the protocol, so maybe not? I know Intellij is way ahead on java, but I've spent most of my career trying to avoid that.
Things like rubymine or phpstorm are definitely areas I have no experience.
Gopls is still miles behind Goland, in my experience.
It doesn't crash, and it handles our extremely large repo without being too slow which is honestly impressive... but the amount of time I've had it "find references" and had significantly worse results than a blind grep, or "go to implementation" sending me to a completely different function signature, is easily in the hundreds. And that all impacts refactorings too, making them worse than useless - an intern equipped with a 5 minute crash course in sed can do better. Finding and fixing what it screwed up takes longer than doing it all by hand in the first place.
Goland's type-level understanding is incomparably better and more reliable. Refactors almost always work automatically. Find usages is almost always perfect, and its mistakes are understandable given the repo and the type system. Call hierarchy actually figures out a call hierarchy instead of flaking out and giving two incorrect results and nothing else. It's trustable. And that's before getting into the absolute clusterfuck that are vscode's settings.
(Why do I use vscode/gopls then? Because its remote editing experience is amazingly good, and sometimes that's more important. Jetbrains' Gateway is largely usable now and improving consistently, but it's very new and definitely not up to that level yet)
- Superior search. Emacs has a better search. It offers way too many different ways for searching things - locally, remotely, recursively, partially, contextually, dynamically, etc. With filtering the results and sifting through and editing at the same time.
- Fine-grained window control. Emacs has some amazing window manipulation capacities. You can precisely control how, where, and what gets to show up on the screen, without having to constantly move things around, drag and resize with the mouse.
- Unmatched extensibility. Can you use Google-Translate to find a word (that you forgot) sitting on the tip of your tongue, then lookup its synonyms in Merriam-Webster, pick one, then check its definition and learn its etymology from Wiktionary? All without having to type a single search query in the browser, using just a few handy keyboard shortcuts, no mouse, no context switching? I just did, and didn't even have to switch the keyboard layout for another lang, I let Emacs handle that.
There's maybe one single thing that specialized IDEs sometimes do better than Emacs, that people often rave about and what earns the label "it just works". That would be intellisense and completions. But, these days, using lsp, and having sufficient knowledge of Emacs-lisp you can build your own, superior completion framework. Company, Corfu and Capf are incredibly good.
Disclaimer, I used Jetbrains products for many years and still sometimes fire up Android Studio (mainly to check how something works).
Sure, but how difficult would be to get them to work together? I dunno the specifics of those plugins, but let's say: one of them translates the best to and from French, and two others are great for Spanish. How difficult would be to run them all at once and collect the results to display in a single window?
In Emacs, I can feed the word at point to a bunch of local and online services and show the results in a single buffer, or insert them at cursor, or export to html, pdf, etc., or automatically send somewhere, or print. It would take me a few minutes and probably no longer than a dozen of lines of elisp. I wouldn't even have to save that code. Or restart Emacs. Or install any additional plugins that would require me to restart it. I wouldn't have to write code from scratch if I could reuse existing plugins. I can even suppress their desire to display things their way by tapping into their internal functions and force them to run my code instead. Which of that is possible in IntelliJ?
Having a similar feature "like in Emacs" doesn't make it exactly as powerful as in Emacs. In order to understand what makes Emacs so extensible, first, one has to grasp what makes Lisp so flexible. But that's a conversation for a whole 'nother topic.
Others have/will answer the question directly, I'll note that you don't actually have to choose for some features. I've seen people using JetBrains to do the refactoring while using emacs for all of their editing (keeps their entire workflow consistent between projects that can all be done in emacs).
I'm not familiar with the JetBrains stuff, but I gather it provides functionality much like Eclipse does for Java. If that's the case, well I've been using Emacs for well over two decades and except for one abortive attempt in the mid 2000s I've never even bothered to use it for Java. The advantages of having a Java IDE that fully understands the code being written are just too great. The LSP is nice because it brings a kind of lowest common denominator for IDE style features to basically any editor, but I don't get the impression that it can match specialized IDEs.
Jetbrains IDEs have pretty good emacs keymaps and very consistent interfaces so I find that they work very well with emacs. I'm switching between IDEA and emacs (and sometimes CLion) all day at work. With some configuration it feels quite seamless. I even remapped Office bindings to match!
I never could make it work when I was using vim style key bindings because the vim emulation modes in every programs end up being slightly different.
as a user of both emacs and JB I would say question is incorrect, emacs is not an IDE, but it can be of course. My opinion that if you have JB IDE it's not worth it to try emacs as one, because even if you do, it will not have any advantage over JB and most likely will be lacking somewhere (like, amazing IDEA database plugin, the one that evolved in DataGrip).
since parent comment is about EXWM, it's pretty awesome to run JetBrains inside an emacs buffer.
IMO, it's strictly worse than JetBrains for refactoring/autocomplete since JB has really nailed that stuff.
However, it's really useful as a compliment, specifically for git interactions (magit) programmer notes + run configurations (org-mode) and all kinds of minor tools. TRAMP is very useful if you'd like to edit remote files, and I find undo-tree priceless when debugging things that have multiple possible failure modes.
Emacs (unlike most IDEs) doesn't unpredictably and non-deterministically mis-interpret your keystrokes when you type ahead by sluggishly popping up completion dropdown at random times that change the interpretation of subsequent keystrokes, forcing you to concentrate your entire attention on the screen, type slowly, and wait for the timeouts to expire and popups to draw before reacting to them.
I learned Emacs at 300 baud, so I'm very used to its ability to perfectly support predictable type-ahead.
Also, it was a terrible for Emacs to make "line-move-visual" be true by default, because it ruins keyboard macros.
Xah Lee disagrees and thinks line-move-visual is great, and rants and raves about it, but his arguments don't convince me. However it was a nice try, and I admire his dedicated Emacs fanaticism, even if we don't agree on the (important!) details.
He didn't address the problem that line-move-visual ruins the usability and determinism of keyboard macros, and I think keyboard macros are so important that fucking them up (especially in the service of making Emacs act more like Microsoft Word, which wasn't designed to support keyboard macros) makes Emacs unusable. I strongly agree with the late Marc Crispin's classic flame and followup discussion on the subject. (Search for "M-X fart-noisily-with-spray".)
>This page discuss a new feature in emacs 23.1, that pressing the down arrow key moves cursor to the next line as seen on the screen, not by EOL (end of line character), controlled by the variable line-move-visual.
>[ Mark Crispin ] [ https://en.wikipedia.org/wiki/Mark_Crispin ], inventor of the email IMAP protocol, one of the earliest user of emacs (before Richard Stallman), posted a message on newsgroup comp.emacs, aggressively attacking a emacs 23.1 change about how the key C-n or arrow keys move the cursor across lines. The thread now has over 110 messages. The original thread is here comp.emacs, some later messages are posted to gnu.emacs.help.
>In his opinion, emacs should not have changed this fundamental behavior. Here are some of my responses in the thread, summarizing why i think it is a good change.
He quoted both Mark's flame on comp.emacs and mine on hn:
>Rants on Emacs Visual Lines by Don Hopkins and Mark Crispin
>by Don Hopkins, 2013-12-21
>The wrong people have been drunkenly driving Emacs into the ditch for the past decade or so, and they're really screwed it up in so many ways, usually trying to be way too clever and solve problems that really aren't worth solving.
>They made “line-move-visual” the default, which in the service of making Emacs behave more like Microsoft Word, it makes ^N and ^P across wrapped lines stay on the same line and move to the part of the same line that is wrapped above or below the cursor, totally breaking type-ahead predictability and keyboard macros. That totally pissed of the late and long time Emacs user Marc Crispin, and he explains why it's such a terrible idea that breaks keyboard macros: http://compgroups.net/comp.emacs/line-move-visual/274792
>It totally breaks keyboard macros, one of the most important things about Emacs. It definitely should not have been made the default, since keyboard macros are a way of life for real emacs hackers. I totally agree with Marc's take on the problem, and I am terribly disappointed that RMS let somebody get away with changing it that way, and making that horrible mode the default.
>They just can't stop trying to make it more like Microsoft Word, while failing to actually achieve that goal, and only succeeding in inflicting half-assed solutions with harmful unpredictable side-effects on the users.
>What mindless cretin thought that it should be a good idea to make
line-move-visual be the default in emacs 23?
I just found out about this charming "improvement" in the worst possible
way. Investigation determined that a "routine" software update had just
installed emacs 23 and gave me this "improvement".
>People wonder why everybody hasn't dumped proprietary desktop software.
This is an example why. Emacs' line behavior has well over 30 years of
history, and some bagbiter goes and changes it BY DEFAULT.
>Add all the cute new features you want. But leave the goddamn defaults
alone.
>If you want to have your own playpen where you twiddle defaults to your
hearts content, have at it. But don't pretend that you produce software
for a production environment, and stop telling the Linux distributions
that they should "upgrade" to your "improved" versions. People doing real
work depend upon those distributions.
>It does no good to say "read the release notes" when the affected users
don't get the release notes and don't even know that a new release
happened. It is also unreasonable to expect users to subscribe to every
obscure newsgroup, forum, and wiki to hear about changes that will turn
their expectations upside down.
>Yes, I fixed my .emacs file. And I'm putting in the same change to all
the .emacs files on all the dozens of other machines I use, even though
they still have emacs 22, because otherwise this unpleasant surprise will
repeat itself over and over again.
>Grr.
[...]
>From: Mark Crispin, To: comp.lang.emacs
>They made the wrong decision. Changes to default behavior are a bad idea.
Changes to default behavior of the most basic functionality are an
extremely bad idea.
>I don't care if M-X fart-noisily-with-spray changes its default scent from
skunk to lemon. But I damn well do care about the most basic operations:
all CTRL single letter and ESC single letter. After 33+ years of using
emacs, I expect these to be reliable and not suddenly change.
>I wasted hours trying to figure out what the hell was wrong with my file,
or my terminal emulator window, or my system. The fact that the problem
went away on a different system added further confusion. It was only when
I did ESC <n> CTRL/N and saw that it moved me the wrong number of lines,
but only on one system, that I realized that emacs changed. And that's
when I did ESC X describe-key CTRL/N and read about line-mode-visual,
although it did not mention that this was now the default.
Hah! Brings back memories of a 300bps dialup connection to a DEC-20 machine using a VT-100 terminal; I was thrilled when my institution upgraded me to a 9600bps modem (because a 19.2K modem was just too much money).
