For me, the power of Emacs is mainly that I can do everything with the keyboard, which is not only much faster, but also - to me - much more enjoyable than going through visual menus with the mouse.
For someone not good with the keyboard, it's probably a nightmare. I suppose it's good for power users and terrible for casual users, and I don't know if there's any way to really build one user interface that works equally well for both, it's usually a compromise.
The next best thing I love about Emacs is that I can do anything conceivable with code. This one is an even larger gap between power users and casual users.
I think tools like that are just fated to only attract a select few.
When I got into emacs 20+ years ago the "use only the keyboard" thing was a huge point of pride and to this day I don't understand why. Who cares? I use emacs because I can code the entire environment.
Fundamentally the mouse is just a form of modal editing. Emacs supports this in spades of course, and god-mode is my modal input minor mode of choice, but clicking to jump to a position on screen can often be a lot faster than I search or avy-jump commands, say nothing about how much gentler on the wrist it is. Then you can customize the menus and toolbar icons so you can be 1-2 clicks away from something that would otherwise require a chorded keypress or worse, an M-x command.
Then you have the biggest benefit of using the mouse: scrolling around reading code or text while having a drink or snack in the other hand. These days I use a trackball in my left hand. Regardless, the keyboard vs mouse thing always struck me as one of the many dumb flamewars that tech people engage in.
> Regardless, the keyboard vs mouse thing always struck me as one of the many dumb flamewars that tech people engage in.
Certainly. I wouldn't argue that text editing speed is a relevant bottleneck in software development, actually. To me it's enjoyable and that's a big factor in my productivity, but that's just me.
My point was mainly that the keyboard (efficient use is difficult to learn) vs mouse (arguably easier to learn) is just one example of why the current desktop metaphor won over something I'd say is designed for heavy keyboard use (even if usable without it). The "code the entire environment" thing you mention is another example. Not sure I expressed that point all that well, rereading my comment it almost looks as if I'm trying to start a flame war :D
I think this largely misses the point. It isn't about which out of keyboard vs mouse is objectively better or faster. It's about subjective comfort. If a system "feels" nicer to use then I'll feel more motivated while using it which means I'll use it more and be more productive, and that's a sufficiently good reason to prefer one over the other. For me, that means using the keyboard and not the mouse.
You can but that doesn't neccesarily mean you should.
I tried it for a while, after seeing my Eve Online friend skipping through tasks at a rate of knots without any mouse movement. My god the amount of tab pressing I had to do to get anything done was crippling. I might have to jump through 15 times to get to something that would take me less than a second to click.
Emacs is great for people who are fine tinkering with their tools, and adjusting them to their needs and tastes. Emacs improves my quality of life quite a bit.
A lot of people hate that, they want a tool that has all relevant to their tasks front and center, all irrelevant invisible or nonexistent, and zero options to tinker with. It should just work, and preferably never change.
A middle ground are the browsers that just work out of the box, but can be heavily customized by extensions. MS Office is another example.
> A lot of people hate that, they want a tool that has all relevant to their tasks front and center [...]
A lot of people don't even know how to use their tools properly. I remember when I was teaching a number of Perl courses to programmers, they where joking about me using emacs while they where using vi or vim.
But while I watched them while they did their exercises, I constantly heard the "bing" sound when the cursor hit the end of the line. Why? Because they pressed the cursor key and waited for the cursor to travel to the end of the line, then chynged to insert mode to append stuff.
Even I, a humble emacs user, knew that there was a vi command to jump to the end of the line and append.
> they want a tool that has all relevant to their tasks front and center, all irrelevant invisible or nonexistent
That is Emacs. You just have to drag the relevant up first and push down the irrelevant.
The thing is in Emacs, most utilities don’t want to presume how you would want some feature. Even if they do have defaults, they are suggestions at most. Instead of getting a tools that you have to learn and conform too, you get the template/idea/inital_version of a tool, and you make it your own
And there’s the whole idea of integrating stuff instead of isolated utilities.
But that's just culture, and quite easily moldable. Lots of people would also rather gamble watch smut all day, but we decided that it's not the best way to go about life... so we set up a system (school) to manage their learning process, and shepherds them for well over a decade, and then involves them in the economy and in society. Likewise we have cultural mechanisms which try to ensure that people learn essential skills related to nutrition, mobility, relationships, etc.
A lot of this has been eroding in recent years under the banner of convenience, and will likely have pernicious consequences in the coming decades. I posit that letting the insidious patterns broadly drive our approach to computing is similarly dangerous.
It seems a curious attitude for a developer, though. My curiosity about how things work and the joy I get when I make a computer do the specific thing I want it to do for me are the reasons I program for a living.
I fit into this category so I might be able to explain. I'd like to learn emacs and build my perfect config for my WM and so on, but on top of that theres a long list of other stuff I want to do and build and learn. My time is finite and with all the other demands of life, my energy even moreso, so naturally I have to make sacrifices.
That doesn't sound like you "hate that", more like you're making a time management choice. I'd challenge it, as I find time spent on creating a good developmemnt environment pays off very well in overall productivity terms, up to a point, but it's your choice to make. Emacs certainly isnt for everyone, even among those that enjoy tinkering.
Life is full of decision points. It is very understandable to use your decision budget on things that matter, like your projects or your job or your money, than things that don't like an editor config. Over my decades of emacs use I've had periods of crazy tinkering and conversely years of doing nothing.
Completely agree. At the same time, I'd wager a good chunk of developers isn't really in it for a love of computers and tinkering. Not a bad thing per se, just my observation.
I actually discovered that emacs is great as it is out of the box (except for creating annoying backup files with ~ at the end). I use it instead of nano and vim.
Emacs took a wrong fork in its own metaphor. At length, being able to take code and libraries between production and the editor would be a game changer. While Elisp has design features that make sense, in the tradeoffs, I think it lost to every other lisp with a general purpose programming ecosystem.
I have a hope for the Common Lisp based Lem. All we need is to coordinate enough signal for potential users to feel it's the right time for their actions. Go star Lem https://github.com/lem-project/lem
I feel the same way about org mode. Nice. Can I use it on a team? Get real. I'd like more embedded data functionality in markdown. It's not XML, and that's good. Org is just weird. AFAIK it's still trying to figure out inline data embedding, so the embedding isn't even that strong. Doing something like exporting with a CSS class around a specific word probably uses some awkward literal syntax instead.
There are consequences to the monastic culture around Emacs. It's really good at holding itself in place. If you don't buy that tradeoff, you need to keep shopping.
The more I learn about emacs the more I'm happy I never joined the cult
Don't waste my time with 70s "ergonomics" (if it can even be called that)
The comparisons with art seem almost to the point of offense to me. You're not building art, you're just building another yet plugin for emacs to do what other people do in maybe 5% less efficient ways but won't spend 2 days automating it
Emacs don’t have plugins. Emacs only have a small C core (kernel) that handles very low level details. Everything else is lisp code split into packages (libraries and utilities). And being a lisp means you can alter and redefine any symbol you want.
The thing is that, there’s enough packages built-in and by third-party, you never really write your own. My whole config is pretty much setting options and linking packages together.
What's your take on opinionated distros like Doom Emacs or Spacemacs?
I've been doing my daily journaling and task management on Emacs for while now, using Doom Emacs. Rationale was that it'd be mostly pre-configured to a sane standard and that, for actual text editing, I'm a long time vim enjoyer, so evil mode is great there.
However I always feel that when I go beyond the safe borders of the preconfigured, leader-key-accessible realm, I'm quite lost. I don't have good intuitions on how to interact with more raw parts of the system.
And I do want to venture further, so I'm feeling I need to get re-started with one of the recommended tutorials/books.
Should I start fresh Emacs install instead?
PS: I've coded in a bunch of lisps in the past and I have already done a bit of customization on top of Doom, so I sort of know my way around, but I'm just not comfortable I guess.
Whatever works for you works. If you want to use your editor for a goal, using the guardrails of Doom is fine. I use a vanilla setup as my base but I've been using emacs since before distributions. If you want to tinker or otherwise learn emacs more deeply, feel free to start from a vanilla config.
I'm in the same boat and curious if other more experienced users have any resources to point to. My anedoctal data point is that after starting with doom emacs and having problems to set it up on another machine i fund out all i needed was a very small configuration file to accomplish my orgmode/agenda usage needs. So all it took was an issue and a clear vision of the goal to find a way through. Maybe it is a healthy approach to keep the complexity manageable to your usage
My petty opinion is that distributions which disable the menu bar are bad, distributions which use an edgelord dark theme are bad, and distributions which do both are terrible. Where Doom in particular is concerned I dislike the fact that it starts with Vi keybindings by default (I quite disfavour modal editing, there's a reason I switched away from Vim after 5 years) and that it changes the 's' binding so I can't even rely on my muscle memory.
I've tried both Spacemacs and Doom (and others like Witchmacs and Bedrock) and now I'm just using my own 800 line init.el (which does include comments and whitespace so the actual LOC will be lower) and 110 line custom.el (if you set the custom file to a different file than your init then using customize to change settings won't mess things up if you manually edit your init).
If you really like Doom you can try reading its code base, if it's just too much then maybe it would be better to try setting up your own configuration from scratch.
I think some of these are unfair criticisms, because they are things that can be trivially changed. E.g. disabling evil mode or changing the theme are one-line modifications in the Doom config. After all, any opinionated Emacs distro has to make some choices otherwise there would be little point in anyone using one.
For me the issues with Doom are (a) the complexity as a whole that it introduces, and (b) so many things are already installed/configured that you end up using them without any real "under the hood" understanding which is so essential for customisation.
They have their place. I started out with Doom and it definitely helped to streamline the beginner phase where vanilla would have felt overwhelming. But, as with you, I soon became frustrated when I wanted to move beyond its default configuration.
I've since switched to Vanilla and I've been using ChatGPT to gradually explain and help me integrate the Doom features that I like, so that I end up with a similar base that I actually understand and which I can deviate from where I want to.
Don't use them. A personal config is highly personal, and a distro force someone else's preferences onto you. Even things like how exactly your config is organized.
But ultimately it's all about tradeoffs and what works for you. You don't necessarily need to go beyond your distro, but if you want to or need to, then that's a good sign to try it
> Emacs is single threaded, therefore if anything in the system hangs, the whole system hangs
For development work I haven't found this to be an issue. Generally when coding I use very few X apps - pretty much just a web browser and maybe occasionally a PDF preview or docs browser. I don't think I've ever had a problem with the single-threaded behaviour blocking window management there. (And as an aside, while proper threading would be nice for things that actually should be concurrent - such as EXWM's duties as a window manager - I massively prefer emacs' synchronous processing of input over the JetBrains horror of pressing a key combination and then having to wait for some asynchronous UI behaviour to occur, with different outcomes depending on whether the next keypress occurs before or after the UI behaviour the first one triggered.)
For other, more GUI-focused activities I just run a separate (wayland) session.
> This is how world class athletes, musicians, artists, writers, and of course programmers take what is in their mind and translate it into reality.
> It is the ultimate sharpening of the axe before chopping the tree[1]
But if part of our axe sharpening is listening to music, reading email, catching up with your feeds and so on then perhaps we need to take a step back and ask if we're just invading our working thought-space with boondoggles.
[1] "Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” - apparently Abraham Lincoln.
We do various tasks with computers. And it's not always in a linear fashion. What's important is reducing friction. The latter can manifest in various way, like having to battle with a GUI just to play some music, yet another GUI for email, and another one for your feeds. Emacs stuff can be pretty stable and you have the same interface for everything.
A good carpenter takes time to maintain and procure their tools. They still have a nice phone and might listen to music on their headphones while they’re working. A chef must keep their kitchen clean and well organised. Stocked with appropriate and some obscure tools. She must season her saucepan, sharpen her knives.
I keep hearing about emacs and how awesome it is, is there a good resource for a complete beginner who is familiar with programming but not necessarily editors like vim or emacs, just to get started?
A good way to get straight in, is to download `emacs`, open it, and follow the built in "Emacs Tutorial" (click the link on the first page that is shown). It brings a new user through the concepts of the editor, how to move around, do some of the most usual actions, and get familiar with its vocabulary.
At first, it is also a good practice not to install any package, and use the built-in capabilities (`magit` and `org-mode` are now part of the default installation) for a while, the time to discover what comes with the "factory defaults".
Also, for some inspirations, watching videos from `System Crafters, Howard Abrams, Emacs Rocks` to see how some people use it.
It can take a while to get used to everything, or to install packages and customize it to what other editors comes with by default, but the reward is worth.
I strongly recommend the book "Mastering Emacs" by Mickey P. You will need some patience as well, I recommend going slow and steady for a week at least using the book, with a vanilla/standard Emacs install.
It took me about 2 weeks to get productive at first (this was in 2018), and now I use Emacs every day for a wide variety of tasks (programming and notes, mostly).
The book “Mastering Emacs” is nice. But both programs have tutorials builtin and extensive documentation. There’s also various youtube walkthrough videos for features.
The bit about enabling org capture from "outside" Emacs is really interesting. It's been so important for me to have a system that enables me to make notes, todos etc. with extremely low friction. At any time, without my hands leaving the keyboard, I can take a note that is either directly attached to what I'm currently working on, arbitrarily file it somewhere if I know where it should go, or just let it go into the general inbox (the other part of the system is actually getting to those things in the inbox at some point). Up until this point I have had to be "in" Emacs, though, which accounts for most of my time, but not all.
I like eMacs but I feel the whole workflow is wrong. Buffers are a stacked tiled window manager inside your window manager. Your browser is a tabbed window manager, and many other applications are also window managers. I wish any sub buffer of any application was for all intents and purposes a dedicated window, so the WM can take care of the rest. Maybe it’s an adjustment that I could make in my workflow, but a global solution would have been nice. Too late now I guess though.
Exactly. I share the view that it doesn't make sense to effectively have two window managers running (one in my WM and one in Emacs) with different philosophies and shortcuts. But, and in a more general sense this is the great thing about Emacs, if you don't like its default behaviour you just change it.
My "main" org file is 21k lines, it's no problem at all. My laptop is from 2017 or something.
I do sometimes work on files that are 300k lines (don't ask), and while it's mostly fine, once in a while I'll try to use some less common operation that's not very optimized and have to abort it (e.g. don't try to magit-blame that file). But stuff like searching, scrolling, editing, syntax highlighting are all fast.
If I have to open files >100M I sometimes open them in `fundamental-mode`, which turns off syntax highlighting.
For truly large files (gigabytes), there is the `vlf` (Very Large File) package, which doesn't load it all into memory at once, but still lets you search, scroll and even M-x occur (sort of like grep, but more integrated and editable).
Note that this is on Emacs 31 (there have been some major perf improvements in the last three or so releases, and more is coming with the new garbage collector)
In earlier days there were issues with very long lines; these have partly been mitigated in later releases; on the one hand by faster internals, but also a new builtin package `so-long` that can notice very long lines, default 10k bytes, where Emacs probably should give up syntax highlighting etc. to remain snappy.
I finally made the switch to vim when I was working on a really large frontend template that consisted of the same massive repeated block where a small portion of each was different based on a condition.
There was a lot of search and replace, and emacs started dogging it really hard on like the 10th condition block.
Not these days. Native Compilation made emacs a faster and there have been a lot of other changes. In fundamental-mode, emacs can handle really large files. When opening files literally, it's even faster. I have this 104k line org-mode file and it's reasonably responsive. Reverting it takes a while, but the UI does not hang while the buffer is being formatted according to the mode.
I use a mid tier laptop CPU (6C12T). Emacs is snappy. Compared to what it's like now, it was glacial in 2019.
No, but that’s not really relevant, my point is more that all buffers should be windows across all applications.
Emacs for me gets slow when syntax highlighting is on and I navigate to a very long line, text-mode does not have highlighting or the slowness. Most emacs slowness is caused by bad plugins, which if you report may be fixed by developers.
This may sound strange, but I actually think we need just ... one editor.
Now, this is not a "we need to favour vim over emacs". I think this is a stupid war, the vim versus emacs war.
What I mean is ... basically most editors do almost the same exact thing. They look at some buffer for a file and help the user modify this. There is a finite number of operations possible. Why do people keep on re-implementing basic things here? Why can it not be solved once and for all and then everyone uses that implementation?
We really should have that; and then people can decide ON THEIR OWN what kind of editor they want to use. Many years ago I started with crimson editor as my main editor on windows. I have since then hopped to many other editors. My favourite one was oldschool bluefish in gtk2. I am not saying it was perfect, but I found it much easier to go on my poor brain than e. g. remembering all vim shortcuts. But, it would need xorg + gtk2, so if that is not available, then I can not edit things - that's bad. That was (and still is) also one reason why I use e. g. nano. But this in turn requires ncurses and I hate ncurses with a passion (nano is great though, I can recommend it for quick ad-hoc editing; for larger things it is not quite as good, but if you have to just change some value in a config file, nano is really great).
Even then I used only like 20% of what bluefish offered (the newer bluefish releases are also nowhere near as good as the old releases, also because GTK really sucks nowadays). I'd like to cherry-pick on my editor and declare what I want it to be, without needing to implement everything on my own. Why can't we transition into this? Why do we need to reimplement everything almost from scratch? That just makes no sense to me.
We live in the age where AI autogenerates code (which they heavily drew from stealing people's code). Why can't AI autogenerate the best, most perfect editor/IDE?
Step 1. The most perfect editor with all the features is created. We've done it. Everyone can tailor it perfectly to their workflow.
Step 2. People complain that it's bloated, that they don't want 99% of the optional features in the editor, and that the codebase is a nightmare to maintain.
For someone not good with the keyboard, it's probably a nightmare. I suppose it's good for power users and terrible for casual users, and I don't know if there's any way to really build one user interface that works equally well for both, it's usually a compromise.
The next best thing I love about Emacs is that I can do anything conceivable with code. This one is an even larger gap between power users and casual users.
I think tools like that are just fated to only attract a select few.
Fundamentally the mouse is just a form of modal editing. Emacs supports this in spades of course, and god-mode is my modal input minor mode of choice, but clicking to jump to a position on screen can often be a lot faster than I search or avy-jump commands, say nothing about how much gentler on the wrist it is. Then you can customize the menus and toolbar icons so you can be 1-2 clicks away from something that would otherwise require a chorded keypress or worse, an M-x command.
Then you have the biggest benefit of using the mouse: scrolling around reading code or text while having a drink or snack in the other hand. These days I use a trackball in my left hand. Regardless, the keyboard vs mouse thing always struck me as one of the many dumb flamewars that tech people engage in.
Certainly. I wouldn't argue that text editing speed is a relevant bottleneck in software development, actually. To me it's enjoyable and that's a big factor in my productivity, but that's just me.
My point was mainly that the keyboard (efficient use is difficult to learn) vs mouse (arguably easier to learn) is just one example of why the current desktop metaphor won over something I'd say is designed for heavy keyboard use (even if usable without it). The "code the entire environment" thing you mention is another example. Not sure I expressed that point all that well, rereading my comment it almost looks as if I'm trying to start a flame war :D
I tried it for a while, after seeing my Eve Online friend skipping through tasks at a rate of knots without any mouse movement. My god the amount of tab pressing I had to do to get anything done was crippling. I might have to jump through 15 times to get to something that would take me less than a second to click.
A lot of people hate that, they want a tool that has all relevant to their tasks front and center, all irrelevant invisible or nonexistent, and zero options to tinker with. It should just work, and preferably never change.
A middle ground are the browsers that just work out of the box, but can be heavily customized by extensions. MS Office is another example.
A lot of people don't even know how to use their tools properly. I remember when I was teaching a number of Perl courses to programmers, they where joking about me using emacs while they where using vi or vim.
But while I watched them while they did their exercises, I constantly heard the "bing" sound when the cursor hit the end of the line. Why? Because they pressed the cursor key and waited for the cursor to travel to the end of the line, then chynged to insert mode to append stuff.
Even I, a humble emacs user, knew that there was a vi command to jump to the end of the line and append.
That is Emacs. You just have to drag the relevant up first and push down the irrelevant.
The thing is in Emacs, most utilities don’t want to presume how you would want some feature. Even if they do have defaults, they are suggestions at most. Instead of getting a tools that you have to learn and conform too, you get the template/idea/inital_version of a tool, and you make it your own
And there’s the whole idea of integrating stuff instead of isolated utilities.
But that's just culture, and quite easily moldable. Lots of people would also rather gamble watch smut all day, but we decided that it's not the best way to go about life... so we set up a system (school) to manage their learning process, and shepherds them for well over a decade, and then involves them in the economy and in society. Likewise we have cultural mechanisms which try to ensure that people learn essential skills related to nutrition, mobility, relationships, etc.
A lot of this has been eroding in recent years under the banner of convenience, and will likely have pernicious consequences in the coming decades. I posit that letting the insidious patterns broadly drive our approach to computing is similarly dangerous.
It seems a curious attitude for a developer, though. My curiosity about how things work and the joy I get when I make a computer do the specific thing I want it to do for me are the reasons I program for a living.
I have a hope for the Common Lisp based Lem. All we need is to coordinate enough signal for potential users to feel it's the right time for their actions. Go star Lem https://github.com/lem-project/lem
I feel the same way about org mode. Nice. Can I use it on a team? Get real. I'd like more embedded data functionality in markdown. It's not XML, and that's good. Org is just weird. AFAIK it's still trying to figure out inline data embedding, so the embedding isn't even that strong. Doing something like exporting with a CSS class around a specific word probably uses some awkward literal syntax instead.
There are consequences to the monastic culture around Emacs. It's really good at holding itself in place. If you don't buy that tradeoff, you need to keep shopping.
Don't waste my time with 70s "ergonomics" (if it can even be called that)
The comparisons with art seem almost to the point of offense to me. You're not building art, you're just building another yet plugin for emacs to do what other people do in maybe 5% less efficient ways but won't spend 2 days automating it
The thing is that, there’s enough packages built-in and by third-party, you never really write your own. My whole config is pretty much setting options and linking packages together.
What's your take on opinionated distros like Doom Emacs or Spacemacs?
I've been doing my daily journaling and task management on Emacs for while now, using Doom Emacs. Rationale was that it'd be mostly pre-configured to a sane standard and that, for actual text editing, I'm a long time vim enjoyer, so evil mode is great there.
However I always feel that when I go beyond the safe borders of the preconfigured, leader-key-accessible realm, I'm quite lost. I don't have good intuitions on how to interact with more raw parts of the system.
And I do want to venture further, so I'm feeling I need to get re-started with one of the recommended tutorials/books.
Should I start fresh Emacs install instead?
PS: I've coded in a bunch of lisps in the past and I have already done a bit of customization on top of Doom, so I sort of know my way around, but I'm just not comfortable I guess.
I've tried both Spacemacs and Doom (and others like Witchmacs and Bedrock) and now I'm just using my own 800 line init.el (which does include comments and whitespace so the actual LOC will be lower) and 110 line custom.el (if you set the custom file to a different file than your init then using customize to change settings won't mess things up if you manually edit your init).
If you really like Doom you can try reading its code base, if it's just too much then maybe it would be better to try setting up your own configuration from scratch.
For me the issues with Doom are (a) the complexity as a whole that it introduces, and (b) so many things are already installed/configured that you end up using them without any real "under the hood" understanding which is so essential for customisation.
I've since switched to Vanilla and I've been using ChatGPT to gradually explain and help me integrate the Doom features that I like, so that I end up with a similar base that I actually understand and which I can deviate from where I want to.
But ultimately it's all about tradeoffs and what works for you. You don't necessarily need to go beyond your distro, but if you want to or need to, then that's a good sign to try it
> Emacs is single threaded, therefore if anything in the system hangs, the whole system hangs
For development work I haven't found this to be an issue. Generally when coding I use very few X apps - pretty much just a web browser and maybe occasionally a PDF preview or docs browser. I don't think I've ever had a problem with the single-threaded behaviour blocking window management there. (And as an aside, while proper threading would be nice for things that actually should be concurrent - such as EXWM's duties as a window manager - I massively prefer emacs' synchronous processing of input over the JetBrains horror of pressing a key combination and then having to wait for some asynchronous UI behaviour to occur, with different outcomes depending on whether the next keypress occurs before or after the UI behaviour the first one triggered.)
For other, more GUI-focused activities I just run a separate (wayland) session.
> It is the ultimate sharpening of the axe before chopping the tree[1]
But if part of our axe sharpening is listening to music, reading email, catching up with your feeds and so on then perhaps we need to take a step back and ask if we're just invading our working thought-space with boondoggles.
[1] "Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” - apparently Abraham Lincoln.
At first, it is also a good practice not to install any package, and use the built-in capabilities (`magit` and `org-mode` are now part of the default installation) for a while, the time to discover what comes with the "factory defaults".
Also, for some inspirations, watching videos from `System Crafters, Howard Abrams, Emacs Rocks` to see how some people use it.
It can take a while to get used to everything, or to install packages and customize it to what other editors comes with by default, but the reward is worth.
It took me about 2 weeks to get productive at first (this was in 2018), and now I use Emacs every day for a wide variety of tasks (programming and notes, mostly).
I do sometimes work on files that are 300k lines (don't ask), and while it's mostly fine, once in a while I'll try to use some less common operation that's not very optimized and have to abort it (e.g. don't try to magit-blame that file). But stuff like searching, scrolling, editing, syntax highlighting are all fast.
If I have to open files >100M I sometimes open them in `fundamental-mode`, which turns off syntax highlighting.
For truly large files (gigabytes), there is the `vlf` (Very Large File) package, which doesn't load it all into memory at once, but still lets you search, scroll and even M-x occur (sort of like grep, but more integrated and editable).
Note that this is on Emacs 31 (there have been some major perf improvements in the last three or so releases, and more is coming with the new garbage collector)
In earlier days there were issues with very long lines; these have partly been mitigated in later releases; on the one hand by faster internals, but also a new builtin package `so-long` that can notice very long lines, default 10k bytes, where Emacs probably should give up syntax highlighting etc. to remain snappy.
There was a lot of search and replace, and emacs started dogging it really hard on like the 10th condition block.
I use a mid tier laptop CPU (6C12T). Emacs is snappy. Compared to what it's like now, it was glacial in 2019.
Emacs for me gets slow when syntax highlighting is on and I navigate to a very long line, text-mode does not have highlighting or the slowness. Most emacs slowness is caused by bad plugins, which if you report may be fixed by developers.
Now, this is not a "we need to favour vim over emacs". I think this is a stupid war, the vim versus emacs war.
What I mean is ... basically most editors do almost the same exact thing. They look at some buffer for a file and help the user modify this. There is a finite number of operations possible. Why do people keep on re-implementing basic things here? Why can it not be solved once and for all and then everyone uses that implementation?
We really should have that; and then people can decide ON THEIR OWN what kind of editor they want to use. Many years ago I started with crimson editor as my main editor on windows. I have since then hopped to many other editors. My favourite one was oldschool bluefish in gtk2. I am not saying it was perfect, but I found it much easier to go on my poor brain than e. g. remembering all vim shortcuts. But, it would need xorg + gtk2, so if that is not available, then I can not edit things - that's bad. That was (and still is) also one reason why I use e. g. nano. But this in turn requires ncurses and I hate ncurses with a passion (nano is great though, I can recommend it for quick ad-hoc editing; for larger things it is not quite as good, but if you have to just change some value in a config file, nano is really great).
Even then I used only like 20% of what bluefish offered (the newer bluefish releases are also nowhere near as good as the old releases, also because GTK really sucks nowadays). I'd like to cherry-pick on my editor and declare what I want it to be, without needing to implement everything on my own. Why can't we transition into this? Why do we need to reimplement everything almost from scratch? That just makes no sense to me.
We live in the age where AI autogenerates code (which they heavily drew from stealing people's code). Why can't AI autogenerate the best, most perfect editor/IDE?
Step 2. People complain that it's bloated, that they don't want 99% of the optional features in the editor, and that the codebase is a nightmare to maintain.
Step 3. A thousand more editors are created.