For me it's not the "unusual synergy" between its applications that's handy. I rarely have a situation that is significantly faster than it would be in any other editing environment. What makes it amazing to me is the uniformity of it. Everything operates the same, and the keybinds apply everywhere that they're supposed to. There are many programs that are not that way, and it's kind of jarring.
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.
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.
The single threadedness is the thing keeping me from trying it. Emacs with per-buffer threading would be pretty much golden, but I understand the work to get from here to there may actually be nearly impossible.
I haven't found it to be that big an issue.
Three cases that annoy me:
[1] Slow commands like `straight-pull-all`. I may change how I manage packages in the future, since this is the command that really comes to mind. Because it'll sometimes ask interactive questions (e.g. when changing branches, or what to do with local changes), you also wouldn't really want to try to put it into a background process. Perhaps using the new (in emacs 29) package-vc-install when I want to checkout branches. Because it's deliberately invoked, not really a big deal.
[2] Large files with invalid syntax, e.g. missing the end of a block like a function or class, can sometimes take several seconds to parse, during which emacs is unresponsive. I'm not sure what specific conditions trigger it, but it isn't that common.
[3] I added a hook for eglot to format buffers before saving them, and the Julia formatter took 8 seconds or so to start up, but using Julia >= 1.9 and adding precompile statements (which I've upstreamed) has brought this down to <0.5 seconds.
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.
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).
Yes, and this really showed with applications like Hypercard where you could build apps making use of the operating system's widget toolkit. The old Mac OS was based on the Xerox Star, which was in turn a commercial implementation of Douglas Engelbart's original GUI computer NLS. The Xerox Star supported both Lisp and Smalltalk development environments.
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.
> If Jobs did not care a ot Smalltalk the why was Next based on Objective C which is basically Smalltalk grafted onto C.
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 it
People developed these great environments like EMACS and other open source software out of passion, not because they were chasing profits. There are many instances where seeking profits, as in the corporate world, reduces innovation and creates a short term mindset. A lot of the best research comes out of state-funded labs, even the development of the transistor and the computer in the USA, the development of the internet, all funded by the state.
You're painting with broad a brushstroke. Both good and bad things
emerge from the public and private sectors. Despite often falling into
the "worse is better" trap, self-interest is our species' most potent
innovator, modulo purgative events like WW2 when all our intellectual
capital returned to the state.
To be fair, FOSS is pretty much the definition of socialism. Donations are pretty much the only way money is made directly off the software itself. Running an instance of the software, if it's a server for example, is a slightly different story. Everyone contributes of their own volition and interest.
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.
> the definition of socialism. Donations are pretty much the only way money is made
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.
We're falling in the pitfall of ‶left and right are different depending on where you're standing″. I'm 100% sure what you say is true in your country; but in mine, being religious and eschewing the state-based, tax-backed wealth redistribution in favor of the personal, charity-based one definitely puts you as left-wing.
Christianity is fully compatible with a society where people can make meaningful decisions over things which affect them, with democratic control their workplace and community. In fact Tolstoy came to this conclusion, that Christian ideology says we should have no bosses, and not dominate or control other people.
I suppose there are various right-wing ideologies, and some of them may be compatible with Christianity. I cannot imagine any left-wing ideology (which is at best wrong and at worst downright evil) compatible with Christianity.
Rather than of socialism, I’d say FLOSS is a form of (digital) commons, which as GP points out, is a pre-capitalist/non-capitalist form of production and management.
thats a good point, probably people are colloquially using socialism to mean "the opposite of capitalism", but what it really is just one of many alternatives
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?)
Socialism can mean a lot of things. But originally it meant the control and management of society by workers, on a democratic basis, including the workplace.
Connecting the two, having emacs-like text navigation shortcuts work in any halfway-native text input or field, on Mac, now feels so right to me that any platform without that feature seems flat-out wrong.
It's pretty cool. It's even cooler in applications with working[0] Cocoa text widgets, where you can do things like M-u and M-l for upcase/downcase word, transpose, and even an Emacs-like kill-ring[1].
[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.
Comments like this 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 will you know if you like it.
> What both Emacs and Vim have in common is an intimidating learning curve. You can't just dip your toe in.
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).
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.
Spacemacs is slow as molasses on macOS and yes I have the latest Emacs.
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!"
While I have big respect for neovim, it's performance on big files is actually worse than emacs. I've submitted a bug on that upstream - it gets stuck with disabled TS, LSP, highlighting where vim and emacs chew through without any issues. Emacs has its problems but is actually OK performance-wise, if you avoid the obvious (long lines) and less obvious (custom modelines, fancy pseudo-tabs, etc) pitfalls. Thing is, emacs is constantly improving - 28 is faster than 27, 29 will be again faster and solve the problem with long lines.
> 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 :)
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.
> That you believe your editor obviously can't be expected to deal with long lines shows objectivity isn't a concern.
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.
> So... don't mode it? Stuff it offers out of the box is pretty solid these days with minimal adjustments
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".
There is nothing misleading about it - this is how I’ve always ran my neovim configs and it did the job - without project management and hundreds of packages. Don’t trick future readers into thinking this kind of yak shaving is necessary and not a personal obsession.
Your snark doesn't make my Emacs run faster but if it makes you feel better, do continue. ¯\_(ツ)_/¯
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.
> of which Emacs wasted plenty. Chose the lesser evil.
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.
> Your snark doesn't make my Emacs run faster but if it makes you feel better, do continue.
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? :)
> Spacemacs is slow as molasses on macOS and yes I have the latest Emacs.
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.
> One has to carefully choose and pick the modules...
...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.
> 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.
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.
> 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
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.
> 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.
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.
> Thousands of Emacs users never had the experience you described
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.
> What both Emacs and Vim have in common is an intimidating learning curve. You can't just dip your toe in.
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.
This was not my experience with Emacs, oddly enough. I started using it because it was the only editor that both supported a terminal and had a top bar. Like a windows program, pressing F10 gets you a File, Options, etc. menu that helped me get through that first session. Emacs (and other Vi's, I should note) has made a nod towards accessibility that Vim has not.
As a long-time Vim'er who has had a dalliance with emacs a few times before fleeing - I always saw the bar and had no idea how to use it. f10. Nice. What always got me was how it still* felt sluggish on my intel 32gb rMBP.
Performance has improved a lot. I'm on version 28 with native compilation enabled and I just opened a 12599 line yaml file and there is no lag. In the prior version the file was pretty much uneditable in emacs. There are probably still cases where vim outperforms emacs, but for any reasonably sized file it should be good.
It is likely the fault of an extension or misconfiguration. It is instant for me, with ivy typeahead/fuzzy match magic. You would need to start uninstalling packages until you find the offender. I don't know if that is easy with something like doom since a ton is stuff is pre-installed.
Switching Emacs distro sounds like doing a favor to a friend that kept stealing my money but I'll grant you that yes, I'm not using stock Doom and that might be the problem.
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.
Yep. NeoVim + LunarVim gives me that (as long as I don't update it often, lol, it has similar problems -- people over-excited to pimp it forever and ever).
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.
I was a long time vim only user, that lived and breathed in the terminal. Then I found Doom Emacs, and it gave me everything I never knew I wanted or needed. I'd highly recommend giving doom emacs a try. There is also a great series of videos on how to use Doom Emacs on youtube.
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.
I use a Kinesis Advantage2 keyboard that has Ctrl, Alt (Meta for Emacs), and Win at the space bar. Some ergonomic setup like this is going to work much better than the usual suggestion of remapping CapsLock to Ctrl.
I second the suggestion of getting ergonomic keyboards with thumb clusters.
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.
I fixed all my pinky problems by remapping the modifiers from the standard
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).
I have used Emacs for around 5 years now (about as long as I used Vim) and I find the Emacs keybindings more ergonomical. Though that might just be because I have long and agile fingers.
100% agree re: Doom Emacs. Evil mode user and no issues with emacs pinky ;-). It's a perfect match. No concerns about performance either, start my emacs in the morning and close it at the end of the day.
For quick command line things or remote tasks I still use Vim. I know, I know, emacs does all that also.
I don't know for sure what the emacs pinky is but one of the things doom does is maps the ctrl key to space bar, I find myself rarely having to leave home row now.
FWIW vim was my first "serious" editor and I switched to Doom Emacs (which defaults vi keybindings) and couldn't be happier. Although tbh if I didn't have vim muscle memory I probably would've landed on VSCode.
same, and I surprisingly found it quicker to get used to doom emacs coming from vim, than it took me to get used to a modern neovim setup which I also tried briefly
VSCode has vim extensions emulating keybindings similarly to Emacs Evil mode.
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.
you should install doom emacs. it has some vim stuff baked into it and you also get the absolutely awesome git ui that I can't stress enough is the best piece of software written in a long time. sounds like hyperbole but it's seriously so well made.
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.
With the Emacs shell, this goes a step further. Emacs functions and /bin/ commands are put in the same namespace. '+' is now a command that can be run at the command line, while 'grep' can have its output redirected to a buffer instead of a file (Sadly no input redirection). This, all while itself being a buffer.
It doesn't work well with full-screen programs, or ones that use escape sequences. Sadly there's no away around that besides keeping a list of those programs. Unix programs have never needed to say to the OS "I am a fullscreen program" due to how little a traditional shell actually interacts with a programs.
Emacs is my login shell now. I feel however that other, more pure attempts at this like the Canon Cat and Plan 9's text editor were smothered by the Mac/Windows interface of GUI programs which rarely interact. A more evolved shell never had the chance to arise.
I've mostly ditched tmux for emacs shells. I wrote a quick script that gives me tmux like shortcuts for tagging and switching to different buffers. This allows me to start several shells and move between them with simple "Alt-Fn" shortcuts. The split screen modes and copy paste are so powerful I find myself opening emacs just to use the shells even when I don't have any need for a file editing buffer.
That's quite funny. I've ditched the terminal for vim with split screen, for pretty much the same reason that you are using emacs - quicker to shift between shells and copy/paste become so much more (also, searching command history is not intuitive).
Here's my shell script for vimterm.sh:
vim -c 'call Tmux()'
And here's the relevant function from my .vimrc:
function! Tmux()
vsplit
terminal
set nonumber
wincmd j
q
wincmd l
terminal
set nonumber
wincmd j
q
endfun
I never really set up a function for it, but what I usually do is in a new vim instance, I'll run the :term command, press ctrl-w o to make it the only window and then run a nested vim instance in that term window (typically one instance per vim tab). I'll open new terminals by running :tab :term.
Basically, I'm using one instance of vim as a session manager to run other programs in, including vim itself. You can pass ctrl-w to a nested vim instance by pressing
I run tmux in vterm in emacs rather than multiple vterm buffers because as awesome as emacs is it still crashes or just becomes unusable with enough uptime. This way I can bounce emacs without losing my terminals.
I still use Screen/TMux to run servers, or any process that I need to keep running for a long time and still maintain control over it's STDIN/STDOUT.
But now that I use Emacs "shell-mode" I hardly ever use Screen/TMux anymore. I don't even use Bash anymore, I switch my default shell to Dash, because I don't need Bash's tab-complation in Shell-mode. I use Emacs's tab completion instead.
eshell, at least in the past, is quick to involve ansi-term (M-x ansi-term) when launching a program that requires it. I recall being able to run Emacs inside of Emacs circa 2008, not sure if things have changed since then.
Eat is an terminal emulator supporting eshell, written in elisp. It also supports full screen programs.
It claims vterm is 1.5x faster, though, but that eat doesn't flicker while vterm does.
I haven't noticed vterm flickering, or maybe I just don't notice?
I've tried out eat a bit, it does also have something similar to eshell-vterm (for visual commands), but, obviously, in eat. My limited experience is that: (a) vterm doesn't feel like it flickers to me; (b) vterm still also feels faster than eat.
This was the first tricky bit to wrap my head around when using emacs: "Why do they call files 'buffers?' Every other text editor just calls them files."
Wrapping one's head around the difference is IMHO the first step into grasping why emacs sticks around after all these decades.
Every text editor I know of makes its edits to an in-memory copy of the file. If interactive edit commands operated directly on the file, the Save command would make no sense.
Emacs calls the in-memory copy a buffer. (VSCode calls it an editor.)
Most text editors call it "file" or "document," even if it's not yet backed by disk.
It's a subtle difference, but I think emacs's decision to call them "buffers" (though it makes the editor a space-alien by modern standards, that much harder to learn) makes more clear that the user should have no expectation that any of the buffers ever get backed to long-term storage. Once one wraps one's head around that, a lot of things get much easier (including and especially writing document editing functions; where most systems would have you store blobs of text in string variables, emacs really wants you to pop up temporary buffers and manipulate them like any other buffer, with the added benefit that if a function fails mid-execution, the regular buffer editing tools make it easy to inspect the failed state).
The distinction is that buffers are by no means necessarily in-memory copies of files. When you start up emacs, you will have more buffers active that are not backed by files than buffers that are.
The distinction becomes clearer once you start using emacs buffers for things other than text editing; like, say, an IRC client or a command shell, or elisp eval.
It is a direct manipulation interface based around interacting with text. The buffer is where it happens. "Files" or "documents" can be in those buffers. But so can textual sessions of many other kinds.
There is the slight difference, that buffers are directly accessible for the user, while other editors only indirectly let you use the in-memory-data. So, what VS Code calls an editor, is in Emacs a window, not the buffer.
This subtle difference becomes relevant for example when working with multiple views on the same buffer. In VS Code, those views are only getting synced when it's a file on space. But open a new editor without an associated file, and every new view on that content, will become an independent copy.
Oh yeah, it gets even more interesting in large refactors, say an involved rename that requires you check the context before you do so (like not just global search and replace). I do a search, this opens a buffer with all results, with file name, position, all that, and Emacs can allow you to "peek" into the file without even leaving the search buffer focus (i.e use a split screen). Then, use https://github.com/mhayashi1120/Emacs-wgrep to do the magic of in-place editing.
The emacs rocks episode on multiple cursors does a great job showing the power of everything in the buffer. It’s well worth watching until the end, it’s got a wonderful finale https://emacsrocks.com/e13.html
I'm pretty sure when he wrote all of that stuff that he'd only been using Emacs for around a year. The benefit of someone that talented, or groks Emacs immediately, and is familiar enough with the outside-ecosystem to know what he wants to borrow, I suppose.
Speaking of spellchecking... As devs we tend to use lots of weird words and acronyms and they're not, by default, in the spellchecker that Emacs (or other editors) do use (aspell in my case). You can add them but then I take it many of us keep "adding to the wordlist" the same words (for example, yes, "abs", "stdin" and "stdout" are correctly spelled, etc.).
Does anyone know of a good source of "programming vocabulary" made to add to spellcheckers?
Thanks, I just checked Foldoc: there's definitely quite some stuff in there but then I tried terms like "Clojure" and "iptables" (which aren't recent by any means) and they're apparently not in that dictionary but it's a start, I'll dig a bit more.
Dired is just one of the great examples of "everything is a buffer" benefits. It lets you do some pretty gimmicky stuff like for example, converting the textual representation of a directory (the output of `ls -lR`) to a proper Dired structure you can navigate through (google 'Virtual Dired').
One of the more utilitarian examples is the use of Indirect buffers. You can, for example, create an indirect clone buffer of a file, narrow some portion of text in the original buffer, and in the cloned buffer, move the cursor to a different location. And then work with two buffers as if they're related to completely different files - narrowing, widening, selecting and deleting things. And when you save, the changes from multiple places get reflected in the same file. The total bananas about this stuff is that you can change the major mode of the indirect buffer. That for example, lets you edit comments in e.g., python code containing json snippets having highlighting, syntax checking, etc. for json, as if the underlying file is not .py, but .json.
Dired is indeed a neat example. As per the linked post, one fancy thing one can do is make the buffer view of the directory editable, rewrite names for the files using the full power of Emacs editing and then dump the modified file names to disk. It is also cool that a new shell in a dired buffer starts in that directory. If the dired buffer was displaying a directory in a remote machine, then the shell starts in that directory on that machine. Just like things should be.
This is a cool anecdote about something that happened to me last week. I'd love to hear similar anecdotes where people who use Emacs (or Vim, or other software sophisticated enough) were able to combine its features in unexpected ways.
One lovely little thing: since everything is a buffer, autocomplete has more to work with. Specifically I'm thinking of hippie-expand's `try-expand-dabbrev-all-buffers`, which just uses all buffers as sources for 'expansions' for what's currently written. So you type "thi" -> M-/, and because another buffer has "thing-you-want", it is able to complete what you wrote out to "thing-you-want".
This is straightforward when you just think of buffers as being source files in your IDE, but it's not limited to that - you can also complete from a dired buffer, or your compiler output buffer, or your REPL. So you can get a filename to expand, even though no source code file actually contains that filename. If instead of dired and compile-mode you were using a separate file manager, and a separate terminal window to compile, you'd have text in three separate programs and no expectation that the text editor in your IDE would be able to see the other two.
Oh, yes! This is something I use all the time, and it's so natural (I've been using Emacs and dabbrev for about 2 decades now) I don't even think about it.
Changing buffers works just fine in keyboard macros.
So sometimes I'll prepare one buffer with a list of lines that are basically meant to provide input to a macro for editing another buffer and have the macro constantly jump back and forth between them. (E.g., move to a spot in the "edit" buffer, jump over to the "input" buffer, kill the next line, jump back to the "edit", yank that line, etc.)
"Kill" text in a "rectangle" and save its contents
C-x r k
Switch to the scratch buffer (think there's a missing RET at the end)
C-x b *scr C-I
"Yank" the "rectangle" saved in the first command
C-x r y
Moves to the start of the buffer and sets a "mark"
M-<
Literals that are entered at the start of the buffer
(+
Move to the end of the buffer
M->
Another literal
)
Executes the buffer (or at least the LISP expression at the cursor). Note the scratch buffer allows you to type arbitrary LISP stuff and execute it with C-j.
C-j
So, suppose the initial buffer contained
1
1
2
3
Then the scratch buffer would get turned into
(+1
1
2
3 )
And when executed this would add the list of numbers and look like this:
> Switch to the scratch buffer (think there's a missing RET at the end)
In vanilla emacs you need a RET, but I bet that like many people, OP's using a mechanism that will just select the matching item if there's a unique match, rather than the built-in buffer selection mechanism.
I use ido (with flx-ido for fuzzy completions), and it works for me as stated: C-i in the minibuffer runs `ido-complete`, which selects the unique completion if there's only one. (By default, that is, this is emacs and so of course there's a variable `ido-confirm-unique-completion` that you can set to customize this behavior.)
I don't think they were trying to be. Broadly, those are the key bindings to copy a column of characters (presumably numbers) paste them into the `scratch` buffer and sum them, give or take some assumptions
It's far too common that the interface an IDE gives you for something like adding a watchpoint is "type an expression into this small area in a dialog box, using a restricted subset of my text-editing features".
I sometimes think the main attraction of print-style debugging is that it doesn't do that to you.
One example of synergy I have is that of TODO code comments and org-mode agenda scheduling. For context, some programmers leave //TODO comments through their projects. org-mode uses a notation syntax of *TODO to capture and schedule an agenda item for later completion. These agenda items can be scheduled on a calendar and the agenda can be queried for day, week, month TODOS.
Org mode has custom templates for capturing org agenda items. I've made a "TODO code comment" capture template that I can execute on TODO comments. Once executed the template creates org-mode entries which are added to the calendar and link to the comments file and line number.
this is one thing I miss in VSCode. Can you please share the lisp code you have to customize the org-mode for this. This will be a huge favor for a lot of programmers.
I have to wonder if this is sort of an unspoken rebuttal to the recently posted Project Mage[1] and the more amusingly written but equally intriguing "Emacs is not Enough"[2].
Well, I recently encountered a situation where "everything is a buffer" was not good. I had a Common Lisp SLY REPL buffer open and was testing out INSPECT[3]. This puts the REPL in a state where after printing some text it waits for key presses but that's not obvious and I'm using evil mode so q (for quit) just starts recording a macro and I can't enter insert mode because Emacs thinks the buffer is read only. I could only kill the buffer and start anew (while avoiding INSPECT -- turns out SLY has nice inspection functionality of its own but I shouldn't have to know to avoid running some function in the REPL!).
Surely there are some workarounds or bugfixes to be had but the whole REPL-is-a-buffer feels very rough around the edges.
Yes I know of another OS allowing this: The browser. If I rename a file in google drive it's just an input field, and spellcheck works there like in any other input field.
> If I rename a file in google drive it's just an input field
You still have to right-click on it, then select from the list, then click again. You cannot bind any keyboard key for that specific action, you cannot replace it with a spellcheck engine you like, you can't search and replace multiple things based on regexp, no multiple cursors, no vim-like navigation, you can't change things in nested dirs without going inside, etc., etc.
What's the point of your comment here, I honestly don't understand. It's as if we were discussing femtosecond laser (or plasma blade) capsulotomies (eye surgeries), and you'd be like "one French fella invented a method for this shit sometime in 18th century using nothing but a sharp blade..."
Plan 9 makes it easy to search your terminal buffer history (it's in /dev/text) (Ok I shouldn't call it a terminal... it's a rio window with a shell in it... it's not a terminal)
Acme does similar things letting you manipulate the tag line, or body of a given window.
"Everything is a file" can be a nice interface even at the widget/application level.
"Everything is a buffer" in Emacs likely enjoys the same benefits (and predates Plan 9 and Acme)
Man, I really like the idea behind Emacs, of integrating everything in the way it becomes an ID, but I cant just get into it, specially the weird shortcuts. After years in Vim, and Visual Studio, is hard to wrap my head around the Emacs way to do stuff.
Maybe I try again in my next vacation, when I will get some free time.
I'm not an Emacs user so what I'm about to say may be based on totally incorrect information.
Seems to be that Wdired is just a hack that represents file and directory metadata in a textual format (in a buffer in Emacs parlance). It's not obvious to anyone that editing a filename in this buffer actually goes to the file system and changes the name of the file. It's even less obvious that removing rows removes files or directories. It actually sounds rather dangerous to use.
This is not functionality that emerges from some elegant design of Emacs, it seems it's just a hack.
First, Wdired is not the normal mode for Dired. You have to hit a key to activate that mode.
Second, it doesn't actually make any changes to the file system until you hit the key combo to commit them. And the files aren't deleted immediately, even when you do commit; they're just flagged for deletion in the standard Dired interface. You'll have to hit a button to actually "expunge" them from there, and that asks for confirmation again before doing so.
Think of Wdired more as a convenient way to build up a transaction of FS changes.
And since everything is a buffer, undo works just fine until you commit it. Or you can load up fresh Dired view of the original metadata in another buffer and ediff them to verify your changes before you commit. :-)
Jef Raskin, one of the people who conceived the Macintosh at Apple, spent decades advocating user interface ideas that didn't (yet?) reach a wide audience. I recall he wanted the user to be able to manipulate and interact with the filesystem in the same way as everything else, including spell check and correction. This Emacs user manages to do that with filenames within Emacs although it seems a little clunky.
The Unicode has a Unihan_Readings.txt file that can be transformed into a readings-table for Emacs to help you accelerate your learning the character definition and key sequence for input method. To help your eyesight you can configure Emacs to enlarge the East Asia fonts. What I don't know how is to append to the "chinese-ctlaub" input method missing key sequence for input method.
For example, 雈, code point #x96c8, the chinese-ctlaub input sequence is missing. I'd like to update chinese-ctlaub with the reading "woon4".
This is what I did, years back. I created a single Org-Mode file called tasks.org. I didn't know anything about Org-Mode and in general, was a total noob in Emacs.
Whenever I had a question or felt like whatever I'm doing is taking too long or does require repetition, or simply annoyed me for any reason, I would add a new item to that list.
Slowly I learned Org-Capture, which allowed me to add items to the list much faster and without switching contexts. My list kept growing, and that forced me to learn more efficient ways of finding stuff - e.g., Org-Agenda, scheduling, deadlines, etc.
Some items, over time, have become irrelevant so I learned how to archive them. Some problems required basic knowledge of Emacs-Lisp, so I started using Org-Babel to have source blocks where I would write and play around with tiny (and sometimes bigger) elisp snippets. That lead me to the discovery of indirect buffers and I realized how amazing they are.
That single .org file had become a very important part of my life. I started using it for other things, not just to learn Emacs and Org-Mode. By the time I discovered Org-Roam and jumped into Zettelkasten, I was doing pretty much almost everything I do on the computer, in Emacs. Today I write code, check email, browse articles and blogposts, manage all my files, read books, extract subtitles from videos (to take notes), and keep my personal journal - I do all that in Emacs. And it all started with a simple .org file.
Eventually, this approach become my personal philosophy, my absolute recipe for any problem in my life - If you need to solve something, start with a simple list.
It's like learning to ride a bike. It's scary at first, but you once it clicks you will forever know how to ride a bike. And bikes and Emacs both will still be around in 30 years.
Would you rather spend the next weekend learning Emacs, or a React library no one will ever use again in 6 months?
After using Emacs for years (huge fan!) I finally realized that Emacs hinders my productivity instead of improving it. Thus I moved to other tools, sadly, and never looked back.
In this case I would use Text Extractor (part of M$ PowerToys) and Google Translate.
For me the consistency of Emacs lies not only in its user interface
but in stable longevity. Productivity is important, yes, but is only
one dimension in complex decision space of software. What will you use
next year when Microsoft throws its powertoys out of the pram and
Google makes translate obsolete? Emacs is almost 50 years old, and I
hope to be using it in another 50.
> After using Emacs for years (huge fan!) I finally realized that Emacs hinders my productivity instead of improving it.
I always take these kinds of statements with a grain of salt. Please don't get me wrong, perhaps, you had objective reasons to move from Emacs. Maybe you thought they were objective reasons, even though they weren't as such. I spoke to many "former Emacs users", and in most cases, it usually turns out that either: the person had shallow exposure or limited knowledge, or they've never attempted to learn modern Emacs packages and how they can interoperate. In most cases, they've never written a single Emacs package to solve their personal use cases, let alone publish one for the public.
I'm not saying that Emacs cannot reduce productivity. Oh, no, it very well can. And very often it drags you into the rabbit hole of "improving your workflow". It can be extremely frustrating, even for someone "after years of using Emacs" to attempt to fix a simple problem as the desired placement for a window. The complexity of choice can be exhausting. Especially, at moments when you're "in the zone" of trying to solve an unrelated problem. Emacs can get in the way. And most people just can't find the discipline to continue. Often they'd give up, without even trying. And the "novelty bias" of using different IDE creates an illusion that they have wasted time with Emacs.
The truth is - learning Emacs is a journey. You just need to keep going. And at some point, you may realize that there's simply nothing better than Emacs out there that can simplify your workflow and increase your productivity when dealing with textual information.
- 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.
- It 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.
- Its extensibility simply cannot be matched. I just can't imagine anyone building let's say an InteliJ plugin, with a command that calls a function defined in a different plugin but also redefines some specific calls in that function to its internal, private methods. In Emacs, I can pick a function defined (for example) in Magit, look at the source code, and tell it to redirect its internal, private calls to my own substitute, whenever it gets called.
Emacs not only improves productivity. It brings joy to the process of writing. Writing just anything - text, math formulas, or code. But getting to that point is not quick or straightforward.
And of course, just like anything, Emacs is not a universally guaranteed tool to make you more productive or happy. Some people just "don't get it", and that's quite all right. But for many, there isn't a better alternative. You can offer a myriad of other tools claiming that the combination of them makes you insanely productive, and to that, I would say: "great, I'll delegate some calls to them from within Emacs..."
Sometimes I feel like I'm the only one who doesn't care for Emacs.. then I remember the real world where I've never heard of it being mentioned and never seen anyone using it.
There are close to forty thousand McDonald's restaurants. It's the biggest fast-food chain in the history of this planet. That still doesn't make it the best, mouthwatering, finger-licking food. The "real world" is not where every programmer uses VSCode. That would be a dystopia.
The "real world" is a reference to what I experience outside of the internet. With McDonald's my real world experience is that it's a popular restaurant. I don't understand why you're arguing that McDonald's isn't the best. I didn't say Emacs wasn't the best. I said I've literally never seen it used or discussed outside of the internet.
You misread my McDonald's analogy. Einstein once perfectly formulated the meaning of it: "What is right is not always popular and what is popular is not always right". Besides, Emacs is not as unpopular in "the real world" as you think.
You may say it's purely anecdotal. Even label me a confirmation bias gull. But let me tell you my "anecdote". I've been programming for over two decades, and until around 2013, I was just like you. I've never seen anyone using Emacs. I've heard about it. I read some news on the Internet but have never seen it in the wild. And one day, I took a flight from New York to San Francisco. My next-seat guy opened a laptop and started typing things in Emacs. I just couldn't help it. I pretended to be asleep and kept peeking. After forty minutes of that lame game, I simply couldn't hold it anymore and started asking questions. Until that point in my career, I haven't seen anyone coding like that guy - without googling things; without StackOverlfow; without constantly jumping between documentation, terminal console, utility apps, and the editor. It was all in one place. It was clean and strangely ascetic - no toolbars or menu, no icons, no progress bars, no multitude of numbers indicating different things. Another thing that fascinated me was how easily he manipulated window panes using only the keyboard. Clearly, he was "in the zone" - it seemed as if he had zero context switching. That was very different from how I wrote code and most of my colleagues as well. And he wasn't using some esoteric, little-known language. He was writing in Golang. I didn't know it; still, it wasn't some completely alien thing to me.
That flight, though, wasn't enough to inspire me to try Emacs. Soon enough, I forgot about it. Three months later, I made a jump in my career. At my new job, there were a handful of Emacs users. I learned many new things from them (unrelated to Emacs). And that's when I installed Emacs on my machine for the first time. It still would take me another two years to transition. A year later, I got a great offer and bounced again. Better salary, a better workplace, a more prominent company, different kinds of challenges, tougher team - plainly an upgrade from every perspective. In this team, I had more than two dozen developers using Emacs. And that turned out to be a reoccurring pattern for me. With every new team, the more experienced and seasoned developers in it - the chance for more Emacsers would increase. In my current team, most of the devs (more than a few dozen) use Emacs. We have exactly one person using Neovim (there were two, but one left), one VSCode, and a single IntelliJ person. There are probably more non-emacs people here, but in the groups of my immediate proximity, there's an uncontested Emacs majority.
No, I'm not saying that non-Emacs users are lesser and that every self-esteemed coder absolutely has (at least) to try Emacs. Or that it is guaranteed that Emacs would make you a better programmer. No, no. I'm not saying that. It's just, ... In my (of course, totally subjective) empirical experience, programmers using Emacs generally tend to be very good at what they do.
> I don't understand why you're arguing that McDonald's isn't the best
So you see? It's just like Einstein said - "... it is not always right." For you, McDonald's may feel "right" and might be "the best." Albeit, for me, it is not. Our "real worlds" - yours and mine, differ. Today they do. Tomorrow, that may change.
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.