A few things I'd like to have is keymap collisions handling, but as anything in emacs, i can always code it with enough time :)
Comments like make a long time Vim lover like me very curious, but I guess not curious enough to try it. Maybe one day.
What both Emacs and Vim have in common is an intimidating learning curve. You can't just dip your toe in. You gotta jump in head first, sink for awhile and then hopefully learn to swim. Only then you'll know if you like it.
I use Emacs 29 RC with JIT compilation. Seldom any difference at all.
Granted I use a Doom derivative that shows a popup where you see command auto-completion but in 2023 this is absolutely inexcusable, if not laughable.
If it can't work reasonably well out of the box then it is a failure.
I'm already eating down votes in another comment which ironically only cements my decision to move away from Emacs.
> If it can't work reasonably well out of the box then it is a failure.
It is not out of the box though, is it? It sounds like the code that shows you the popup might not ship with stock Emacs.
Do you get the lag if you start Emacs with `emacs -Q`? Do you get it with Doom proper?
Can't promise I'll try again ever. I tinkered a good amount and lost faith. Nothing should need that much time and effort spent to have basic stuff working acceptably.
I think people easily lose perspective. It's OK to love what you do and play with it but people swing too far in that direction and forget that others actually use their stuff and need to get work done with it.
Another thing that Emacs and Vim have in common is Vim keybindings.[1] You can pick Emacs keybindings up at your own pace. From one vimmer to another, if you want to try out Emacs, I highly recommend doing it with Evil.
If you have many years of experience with vim, evil-mode allows you to keep a lot of that and add good stuff from emacs.
Although I am not a fun of vim I ended up using one of those when I needed to switch between VScode on Mac and Windows on a daily basis due to uniformity of keybindings. My only wish is for Vim not to use Ctrl key at all. Then difference between Mac and PC keyboards will not affect muscle memory at all.
I also have the Kinesis advantage 2, and am also a fan of the convex keys. I also ordered a Kinesis 360 several months ago, but have not received it yet.
Started with a vanilla config and remapped caps to ctrl. After a while I got emacs pinky, so I decided to switch to spacemacs and vim key bindings. I tried doom-emacs and a couple of other "emacs-distros", but I kept coming back to spacemacs.
The combination of 'evil' together and chords, like pressing 'fd' or 'jk' in short succession working as an escape key made me rely a whole lot less on the pinky.
A while ago I went all in on rolling my own config, now that I know how I want my environment. Next step for me will be learning to type on a keyboard with a thumb cluster to rely even less on the pinky.
Sometimes I have doubts. I wonder if I am doing this all wrong? Maybe a step backwards would be better - just use gedit or acme and a mouse? Unfortunately, I think I am too far down the rabbit hole to look back up now.
For quick command line things or remote tasks I still use Vim. I know, I know, emacs does all that also.
Ctrl Win Alt Space Alt Menu Win
to
Win Alt Ctrl Space Ctrl Alt Win
which allows me to use my thumbs for ctrl bindings, without using a nonstandard layout (well I'm using a Kinesis Freestyle2 so it's not entirely standard). I also worked on my typing a lot and specifically forced myself to use the ctrl key on the opposite side of the letter key in ctrl-letter bindings.
Not only has it made emacs much more ergonomics it also carries to the keybindings of other programs too, most of which are control key based. Using a hardware programmable keyboard makes it possible for me to use those remaps without admin access or installing any programs in every OS (corporate environment).
You kinda can, these days.
One of the main issues is that Emacs is, out of the box, the most complete toolbox you'll ever see, while at the same time being very incomplete. You have an email client, spreadsheet, unit converter, ASCII drawing, debugger, file explorer and so on and so forth. Meanwhile, you open a Python file and you are lacking a bunch of stuff that the likes of VSCode have out of the box.
So the solution is to customize, and that takes an inordinate amount of time.
Thankfully, some other people have solved this for us:
Spacemacs has VI commands by default - and I don't mean just the simplest keybindings like some VI emulators do, it's using evil-mode and it's pretty good. It can also be used in 'holy' mode (Emacs keybindings).
There's also(the one I use):
https://github.com/doomemacs/doomemacs
Either of these will get you a much more modern Emacs experience out of the box. You may need to add packages (it wouldn't be feasible to add all packages that everyone could possibly want), but they make it easy. Even though Emacs now comes with a package manager, it doesn't have any opinion on how you configure things. Both Spacemacs and Doom Emacs are opinionated, and that's a good thing.
Sure, you still need to learn concepts and keybindings. Thankfully, there's no shortage of tutorials, and Emacs own built-in documentation is very good. It also has a built-in tutorial, which is how I learned.
It became so bad I switched to a Doom derivative (CentaurEmacs) and while it did improve the speed, it merely reduced it from "almost impossible to work with" to "noticeably and annoyingly laggy fairly often".
I gave up on Emacs after trying to make it work for a loooong time. Carefully and slowly making my way through NeoVim in the last 6 or so months now, and it's much easier to work with and configure, not to mention 99.9% of everything is instant (the only time it lagged was opening a source file of 1.7M size and I suspect the slowness came from the LSP server and not NeoVim itself).
Emacs seems to be carried by nostalgia from folks that love to tinker with their tools more than they like to actually get any job done. A bit of a toxic statement, surely, but I'm pretty salty still and I haven't seen any objective evidence to make me look at Emacs and its fans more charitably. For anything and everything the answer always is "hack it for the 6328th time to make it even more your own!"
No thanks. I actually have a job to do.
> Carefully and slowly making my way through NeoVim in the last 6 or so months now
Emacs has also a ton of stuff included, so that you could carefully and slowly make your way through emacs instead of jumping through distros and complaining. In the end, I am pretty sure that you will not be able to freely configure and alter and neovim distribution, such as LazyVim or AstroVim - they have a rather complex structure.
> and it's much easier to work with and configure
No, it is not - it has poor discoverability, you have to reload it on changing the config file. Configuring emacs is a breeze - you can eval blocks of code, check, eval again - until it sticks. Every function is can be called and inspected. Oh, and have you tried to debug your config code in lua? Tell me how it went.
> Emacs seems to be carried by nostalgia
Emacs is carried by the fact that it is the only editor alive almost completely written and documented in it's extension language.
> No thanks. I actually have a job to do.
Of course you do - why else would you jump between emacs and neovim :)
I switched editors because my job was suffering because of impossibly slow Emacs, not because I don't value my free time -- of which Emacs wasted plenty. Chose the lesser evil. Not a hard concept to grasp, I hope.
Shame that you felt attacked and figured you have to be nasty but you helped with exactly zero of my concerns, in practical terms.
NeoVim + LunarVim worked for me out of the box. The tweaks I did were entirely cosmetic. That's valuable. So far I spent exactly 5 minutes on functionality in it -- namely TS and LSP installs.
Oh and if I have to debug my editor then the battle is lost anyway. Not sure why you put any value on that at all; if anything, it's a negative value.
Unspecific complains will not let it run faster, indeed.
> I switched editors because my job was suffering because of impossibly slow Emacs, not because I don't value my free time -- of which Emacs wasted plenty. Chose the lesser evil.
The lesser evil would be to start the included profiler and check what is actually slow - you've wasted more time on complaining here, then M-x profiler-start takes. :)
> Shame that you felt attacked and figured you have to be nasty but you helped with exactly zero of my concerns, in practical terms.
I am not paid to support you, and you've started on a niveau where I also do not want to help you. ¯\_(ツ)_/¯
> NeoVim + LunarVim worked for me out of the box. The tweaks I did were entirely cosmetic.
Oh, LunarVim has its share of bugs, being a complex and fast-developed disto. Since you are not interested in debugging, I am curious what will happen when it breaks - will we see another post with accusations of neovim (another distro you never cared to understand, really) to waste your precious time? :)
Nowhere did I say you "owe" me anything so maybe stop projecting and act like you're personally attacked.
And yes my time is precious.
Correction, Emacs did not waste your time. Emacs did not ruin your life, made you unhappy, or failed you. You simply gave up. Please find some inner courage to accept that fact. Math does not become greater, or lesser, or any other kind of evil just because someone fails to understand polynomials, quadratic equations, or calculus.
You're talking about Emacsers as if they fall out of their mother's womb and blindly walk straight into emacs-lisp mode. Many (if not most) discover Emacs years after trying other tools. We choose Emacs for plenty of good, objective, factual reasons. Not because we're emotionally inclined to tinker constantly or because we have Stockholm syndrome or we're afraid of something.
You have made your choice, fine, congratulations. But please don't come to a civil discourse wearing your preacher's mantle just because you think that "you've figured it all out". Trust me, many of us Emacsers have seen both worlds. And you? Much to learn you still have... young padawan.
---
Just a post-scriptum note: I hope you're not carrying some emotional burden associated with Emacs and something one day will inspire you to try it again. I remember, I gave it up multiple times, but something always would make me come back and try again, until one day I decided to stay. And by the way, I'm a die-hard Vimmer. The revelation that Emacs vims better than Vim itself was huge for me. I wish I had discovered that sooner.
There's a very easy way to read my comments: I want to get stuff done, not tinker with my tools endlessly.
That you believe your editor obviously can't be expected to deal with long lines shows objectivity isn't a concern. And no, emacs29's performance is still lousy on many long lines corpora in the wild, e.g., long parenthetical expressions. Even the improvement on other corpora is now in jeopardy as today the author has admitted the full fix may not hold up under scrutiny and has proposed a significant degradation.
I'm a lifelong emacser, but even I can see why its extensbility is blessing and curse. Sure it's fun to "mod" a Honda Civic, but ultimately you get a vehicle with two more horsepower over stock, and 2^n - 1 additional points of failure where n is the number of mods. But at least it looks cool.
It is a known problem, but I can live with it even in the current state. I have a test where I will take an 800 MB csv file an do around 30 mil replacement in an editor. Vim is the fastest with around 10 sec on my machine, emacs chews through in around 30 sec, neovim hangs and we do not want to talk about VSCode/IDEA etc. But in praxis it is not a limitation which hinders my work in any of the mentioned editors, and so are long lines in emacs.
> Sure it's fun to "mod" a Honda Civic, but ultimately you get a vehicle with two more horsepower over stock, and 2^n - 1 additional points of failure where n is the number of mods. But at least it looks cool.
So... don't mode it? Stuff it offers out of the box is pretty solid these days with minimal adjustments, add magit and org on top, with 29 we get eglot and project.el - happy to roll. The way I see it, if tinkering with emacs if fun, then do it and be happy, if not - don't do it and be also happy. No one is forcing you to mod your emacs and if - report this person to police.
But having this possibility to mod it when you need it - well, it is indeed a quite unique and invaluable trait.
EXTREMELY misleading statement, unless by "minor" you mean "3 days on and off installing and uninstalling and configuring packages", so I had to call you out here.
If I just install Emacs 29 RC I get a useless toy that can't even detect it's in a project and allow me to fuzzy-search a file name inside it while respecting `.gitignore`. Not to mention do a live grep.
So until I can install Emacs and have project features and everything that modern DOOM / Spacemacs / LunarVim / VSCode offer then no, it's not "minor adjustments".
Please don't mislead future readers.
My work here is done. Whoever reads this will know what is there and what is not there with one setup or the other.
Spacemacs and Doom can be slow because they offer tons of modules. You can't blame the buffet owner if you glut yourself till unconscious. One has to carefully choose and pick the modules and packages they need and disable/remove stuff they don't. Typical Spacemacs/Doom config can contain a few hundred packages. Show me a single piece of software that enables you to load hundreds of plugins that seamlessly intoroperate with one another. Emacs can do that, but it's not a sentient super AI, you can't just throw a bunch of things at it and hope it figures that out. Sometimes you even have to set the loading order right.
> folks that love to tinker with their tools more than they like to actually get any job done.
Emacsers hear that shit all the time, and they'd be like "yeah, whatever". But I beg to differ. Nothing else allows me get my job done quickly and with such joy. And I've seen and used many different editors and IDEs. You simply have no idea. Here's a deal, name just a few real-world example use-cases related to text manipulation. Not some goofy vim-golf challenges, something practical. I'm confident, I can probably demonstrate how Emacs does things in a much better fashion than any other editors.
> I'm pretty salty still
You're salty, perhaps because you couldn't spare enough patience and willpower to learn some Emacs Lisp, to figure out how the built-in profiler works, how to troubleshoot things. You've failed to cultivate some curiosity for basic things like, "what exactly happens when I press a key", open a file, etc.
Emacs did not fail you. You just gave up. No, don't get me wrong. I have plenty of reasons to hate Emacs myself. It's definitely not perfect. I hate it, and I still love it. Simply, because there isn't another alternative that I would hate less and love more. Anything else just falls short.
...And you lost me right there. I am looking for a good experience out of the box. Emacs is not it. I don't want to pick anything, even less so doing it carefully.
I only stuck with Emacs because my life has been hell for a long time and I couldn't muster the energy, time and motivation to look for an alternative. The moment I actually had some of these I immediately jumped ship. (And yeah 20 years is a long time, just be grateful your life doesn't have such a big hole in it.)
> You're salty, perhaps because you couldn't spare enough patience and willpower to learn some Emacs Lisp
I don't want to. I am salty because I had no clue what I was getting involved with.
> You've failed to cultivate some curiosity for basic things like, "what exactly happens when I press a key", open a file, etc.
That's not basic curiosity, that's a chore. If I wanted to do kernel development I would, but I don't. I am a user of these things. I will sooner die than go and be "curious" about them.
I want to get work done.
> You just gave up. No, don't get me wrong.
But I said as much myself, didn't I? Though I'll maintain and still claim that it did waste my time, insofar as not making itself COMPLETELY AND PAINFULLY OBVIOUS. I don't care which "function's definition is void", dude. I care about "can't initialize TreeSitter for Golang, we seem to be missing module X which actually should come pre-installed with your Emacs 29 so WTF man, go ask these doofuses maintaining the Mac Homebrew -- the hell are they doing?!", or some such.
You try not getting me wrong either. I am not a script kiddie. I am a guy who absolutely LOVES programming and is doing it for 30 years but is now sick and tired of constantly having to pamper his tools.
I think it's a fair requirement in 2023 to want to run a few commands, make a bash script that updates the editor + its internally used stuff (packages in Emacs, plugins in VIM) and have a basic guarantee their dev setup won't break after an update.
But alas, no.
And to make it completely fair to all sides -- LunarVim (it is basically an opinionated set of plugins on top of vanilla NeoVim, akin to DOOM for Emacs) suffers the same problems. I figured I'll only update once a month now because the maintainers, like the over-excited kids that they seem to be, figure will break everyone's setup every week because they found this awesome new VIM plugin and the previous one is not "elegant" or whatever, bro.
I really see no way out. Nobody gives a crap about good developer experience, you're expected to be on the treadmill of always pimping your tools until your death apparently.
Almost nobody sees technology as a beast to be tamed and made to do work we don't want to do ourselves; they see it as a dog to play with.
If you're a samurai, then sharpening your sword is the single most important non-combatant skill you should master and know how to do by yourself. Sure, you can always hire some peasant who has the skill but shouldn't flabbergast when other samurais laugh at your incompetence.
Knowing your tools and making the best use of them (as a professional) is not part of your job, it is your job. I can still claim to be a carpenter who doesn't use a miter saw because I tried it once and got myself injured. But I can't tell my fellow colleagues to avoid using it and shouldn't complain about how awful those things are. People would laugh at me.
Emacs owes you nothing. It doesn't promise you riches, magical powers or a kingdom in heaven. It's a complex tool, and like any other tool, it requires time, patience and determination to comprehend it. You decided you don't have any of that to spare, so at least have some courage to respect those who made a different choice.
> Nobody gives a crap about good developer experience
The world owes you nothing. Especially, tools like Emacs and Vim. Tools that are absolutely and completely free to get, free to use and free to distribute.
> Almost nobody sees technology as a beast to be tamed and made to do work
That is exactly why I use Emacs. Because I want to feel in control. I am a damn computer programmer, and when the computer doesn't do exactly as I want, yes, I get mad. Emacs gives me a sense of control. You feel differently? Well, then it's you; don't blame Emacs for that.
I've seen your code. You're not.
Framing it as something one-dimensional is not doing your argument any favors. I'll give you a better one: we're virtual samurai with an arsenal of 50 bows, 200 katanas, 150 vakizashis, 20 rifles, 50 armors, 30 horses etc. I choose to not take care of a part of my arsenal because otherwise I'd get no time or motivation to do samurai stuff at all if I did.
There's no need to exaggerate or paint stuff black and white to make your non-existent point feel important.
If you think I am a crappy programmer for not being interested in "What happens when you press a key" then feel free to do so. I'll sleep quite well knowing you believe something so wrong. And you'll never succeed in making me believe like you do. Don't be thin-skinned and accept it.
> Emacs owes you nothing
If you wanted to discuss constructively you would have concluded several comments ago that I had wrong expectations towards Emacs, and that one day I finally understood that, and thus moved away. Which, newsflash, is exactly what happened.
That you and others felt personally attacked and then felt the need to exaggerate and paint me with negative colors (no, I don't "complain") speaks ill of you, not me. I am a pragmatic who finally woke up to the fact that a tool he used for a long time does not match his optimal work and thinking process. Reading anything more into it is just your fantasy.
> don't blame Emacs for that
Only you and a few others in this thread do the "blame" thing. I have expressed my opinion, salted with some negative emotions due to frustration and misalignment of expectations. If you don't like that, well, you'll have to find a way to live through it.
> The world owes you nothing
You're projecting super hard, dude. You over-fixate on an image of a bad programmer that doesn't do X or Y and thus they're "bad", then you figure I am a personification of that image (and it's exactly where you're hilariously wrong), and the rest is as predictable as a ChatGPT prompt; I could have written 90% of your comment if I wanted to argue with myself from another account.
People like you who can't accept different paths to enlightenment exist make for very bad leaders. I hope you're not managing people.
> when the computer doesn't do exactly as I want, yes, I get mad
And I am the same, which makes us arguing all the more funny, absurd and meaningless. Only I choose to do my job for which I am paid, and you choose to do that + tinker with your tools (which I also do but to a lesser extent). Tell me, why does Emacs need tinkering at all? If you are good at it, why haven't you tamed it like 10 years ago, forever? One would think you're bad at Emacs Lisp!
Finally, I tinker with stuff quite a lot -- which seems as something you think I don't do and you take me for some fool who can't write a single algorithm if his life depended on it. And you're wrong. Stop being angry that I don't have the same priorities as you and maybe you'll see a human being and a programmer who gets a lot of stuff done but is sick of pampering his editor programs. Because yes, that's me.
And I just finished writing scripts for migrating Borg backup repositories to Kopia and Restic a day ago because I don't know why... I just love backups. Tinkering. Nothing I got paid to do. I just love it, was curious, did it, was super happy with the result.
I had no problem with your opinions, until this passage:
"Emacs seems to be carried by nostalgia from folks that love to tinker with their tools more than they like to actually get any job done."
That was a quite disingenuous statement. A lot of people who made breakthroughs in the industry used Emacs in the past, and some even use it today. I'm sure you didn't mean to say that Donald Knuth, Yukihiro Matsumoto, Guy Stele, Simon Peyton Jones, Rich Hickey, Joe Armstrong, and many, many others "don't care about getting job done", right?
And let me re-iterate once again, your negative emotions are yours only. They are wholly subjective on this matter. Thousands of Emacs users never had the experience you described. And your generalizing statement exacerbated it further. I would've maybe even accepted that there might be just a bit of truth in your opinions, but that angle pushed them all into the corner where they don't reflect true, undeniable facts about Emacs.
I'm not sure what you expected. Coming to a thread on a specific topic, brandishing a faulty generalization about people and asking to be more constructive? Don't you think that's somewhat narcissistic? Well, whatever makes you happy. I should've known better and instead of wasting time with you, I could've done some Emacs tinkering. But unlike you, I wouldn't blame someone else for that. Mea culpa. I own it.
Which is a shame because that has misled me that Emacs is a trouble-free experience in the past. Wish I was one of those thousands.
> Coming to a thread on a specific topic, brandishing a faulty generalization about people and asking to be more constructive?
For starters, I didn't claim anyone is lacking basic curiosity or implied they are bad programmers, didn't I? Escalating from a point of subjective opinion of someone (me) to these things is still unjustified.
> they don't reflect true, undeniable facts about Emacs.
Another undeniable fact is there are golden paths, and anything outside them is pain. Sad but true. Not only for Emacs but for a lot of software.
Makes me feel super lonely when I write stuff that can parse configs from 3 major versions ago and accounts for partial parsing failures. I know I am not the only one but hell, there aren't many of us out there sadly.
> I should've known better and instead of wasting time with you
You should have known better indeed. If somebody is as jaded as myself, the only way to them is to give them a practical solution that will take them 3 minutes. Everything else is doomed to fail because I tried almost everything else there is and was unhappy with the results.
Next time less preaching, more practical step-by-step articles. ;)
---
Ninja EDIT: just LOL, after 2 weeks of me not starting Emacs but having it run its package updates from the CLI, and now I am greeted with this:
"Symbol's value as variable is void: treesit-language-source-alist"
Seriously. I am only doing what's recommended to do: periodically update packages. And this is the result.
Honestly, that's just sad.
doom emacs. press spacebar to get a menu of things you can do and you also get a bunch of vim stuff for free. I don't use emacs as a daily driver but I still use it exclusively for the magit mode for git.
a caveat that you should be aware of is that you do need to learn a bit about emacs. what's a frame/buffer and how to kill them but that's not too bad.
This is the best summary of what the original Macintosh was all about and why Macintsoh enthusiasts back then loved System 6 and upwards.
(They didn't call them keybindings though. Keyboard shortcuts. (Ironicly a longer word. (yes)))
Unfortunately, Steve Jobs didn't care about Lisp or Smalltalk, and he hated Hypercard, and he took the company's product lines in a consumerist direction, which is why Apple has "app stores" nowadays instead of a thriving ecosystem of tiny Lisp programs that compose well with each other.
I suspect the reason that the Lisa was not Lisp or Smalltalk based is due to speed and cost of memory.
That is a good question, I don't really know (or maybe I am misinformed). Somewhere along the way, Richard Stallman started GNUstep, and Sun Microsystems and NeXTstep founded the OpenStep standard. But it is strange to me that when Jobs started NeXTstep his engineers choose Objective-C instead of trying to license or port Smalltalk, I was under the impression that Jobs didn't care for it for some inscrutable reason.
I do know after Jobs left, Macintosh Common Lisp (MCL) continued to see some development, and there was even a version of the Hypercard product that could be programmed in Lisp (I can't remember what it was called). But when Jobs came back he obliterated all of that in favor of all the stuff they acquired from NeXTstep. MCL eventually became Clozure Common Lisp which is still in development.
I think BeOS (now Haiku) does a better job making everything object oriented in the way that Smalltalk does. I have also heard (though I've never tried it myself) that OS/2 also does a much better job making a fully object oriented system.
> I was under the impression that Jobs didn't care for it for some inscrutable reason.
i dont remember where i read it, but i distinctly remember somewhere that he said something like "don't use any object oriented stuff, its too slow" to which his subordinates went and did it anyways... kinda like the floppy disk in the mac, devs did the right thing in the end even if he originally didn't want itif thats wrong i'd love to be corrected though!
The only thing that can happen is if someone can find the quote and confirm your memory.
I'm not a fan of government-enforced socialism or communism. But if you can get enough people together to willingly participate independently, I'm chill with it. And FOSS software is an example of it working out alright.
That's not the definition of socialism at all.
If you think about it, it's actually much closer to the principle of right-wing Christian charity rather than the left-wing sharing of means of production.
Many in the US tend to associate Christianity with right-wing ideology, but there's actually quite a few examples of a varied history of left-wing Christian thought and action. Sticking to US history: Reverend Martin Luther King, Jimmy Carter, Dorothy Day (https://en.wikipedia.org/wiki/Dorothy_Day). Outside of the US, Liberation Theology in Latin America was an ideology/movement explicitly linking Christian (mostly Catholic) teachings with Marxist-inspired struggles for workers' rights (sometimes those links are easy to do, if you focus on quotes such as "blessed are the poor").
I do agree that FOS software is not socialism, and that donations aren't socialism. But it's important to note that many people who work on FOS software do so without expecting anything in return. I think that idea is in sharp contrast with typical right-wing and centrist economic theories that view human beings as mostly money-driven, self-centered individuals.
Did you mean right-wing ideology? (Calling @tptacek and @patio11 ....)
Pretty sure Jesus never said anything about the forced redistribution of wealth against your will being good.
Jesus actually did have a pretty clear statement in favor of taxes, the most common form of forced redistribution of wealth. https://en.wikipedia.org/wiki/Render_unto_Caesar
on that usage then i think the proper wording for "the opposite of capitalism" would be something like non-capitalist (or even anti-capitalist maybe?)
(apologies for the depression)
There was a common hardware. It ran Star, Lisp or Smalltalk - but not at the same time. Each were whole operating systems.
[0]: Unfortunately in most third party web browsers and Electron apps (Chrome, Firefox, Slack, etc) most of these shortcuts don't work for some reason.
[1]: https://developer.apple.com/library/archive/documentation/Co...
I started using tiling window managers a few years ago. These took a little configuring. I always had one monitor with an emacs session, and then another with an internet browser, and a terminal running tmux, which again needed a bit of configuring.
It took me wayyy too long to finally try EXWM[0]. Suddenly, I have that uniformity and consistent experience everywhere, and only a single configuration language to learn and use to get things how I like them.
If you like both emacs and tiling window managers, I strongly recommend it. My only major gripe is that the single threadedness can be bothersome on occasion, when certain commands can render it unresponsive. But it is still well worth it for me.
Odds are you'll find a few different issues specific to your workflow, but hopefully they'd be infrequent or easy enough to solve or workaround.
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.
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.
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.
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 if not thousands. 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)
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.
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.
- 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).
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 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.
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".)
http://xahlee.info/emacs/emacs/emacs_line_move_visual.html
>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:
http://xahlee.info/emacs/misc/Don_Hopkins_Mark_Crispin_rants...
>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.
[...]
http://xahlee.info/emacs/misc/Mark_Crispin_emacs_line_wrap_r...
[...]
>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.
>Surprise. Grr.
Hah! Brings back memories of a 300bps dialup connection to a DEC-20 machine using a VT-100 terminal — and was thrilled when my institution provided me with a 9600bps modem.
Also, every buffer is a blender of modes. Want a new feature or some handy functionality? Activate a mode.
My only argument against Emacs used to be its sluggishness, but that's no longer a thing with native compilation. So now I'm pretty sure Emacs has spoiled me, and I'll never be able to enjoy another text editor again.