I posted a link here to a Reddit post that said “if you could change one thing about emacs what would it be?” It had almost 200 comments. Some answers definitely touched on these points. But for the most part, what Emacs users wanted was for the Gnu Emacs maintainers to do was…
1. Switch out Elisp for a Common Lisp or Scheme
2. Update the way Emacs Ui Core so it used standard GTK or something better. (The current implementation uses a lot of ugly hacks to support a subset of GTK)
3. Ability to scroll without bringing point along with me so I can quickly check something off screen then just continue typing where I left off.
4. Improve threading so that things like TRAMP didn’t freeze when you were connecting
5. Fast/Arbitrary graphics support
I think for most Emacs users it’s a performance thing. Though the improvements to the GUI code would go a long way to making it easier to make Emacs be more user friendly.
In terms of this article. I think all of this is possible in a separate distribution of Emacs right now. Emacs will never turn on most of these things by default. But maybe if a version of Emacs that makes these changes becomes wildly popular, the current maintainers would be more amenable to it.
Yes, if you ask people who know how to use emacs what they would change, the answer is going to be very different from the answer you’d get asking people who have tried to use emacs and gave up.
The documentation does really suck. The terminology makes no sense to users not used to it. It does not explain that to make this into a functional system, some configuration needs to be done. It is terrible out-of-the-box. ‘Because this is how rms did it 45 years ago’ is not really a good excuse.
The documentation does _not_ suck. It it literally the most well documented software in existence, a reason for which it has been used for many different things outside its original purpose of text editing.
Yes, it may not be for everyone. But just say that, that it uses certain conventions that are likely outdated for a reasonable set of the population. But you can't say the documentation sucks when you have the below:
That documentation is thorough does not mean that it is good.
If anything, one might argue that Emacs documentation being so extensive while buing built around idiosyncratic conventions makes it worse, not better, for many cases: it means it is even harder for people to actually find relevant parts of the documentation.
`You can also type Meta characters using two-character sequences starting with ESC. Thus, you can enter M-a by typing ESC a. You can enter C-M-a (holding down both Ctrl and Alt, then pressing a) by typing ESC C-a. Unlike Meta, ESC is entered as a separate character. You don’t hold down ESC while typing the next character; instead, press ESC and release it, then enter the next character. This feature is useful on certain text terminals where the Meta key does not function reliably.`
Emacs is the self-documenting editor for a reason. I always found the documentation very good. I submit that every sufficiently complex system will need some terminology specific to the system the user will have to learn. Not wanting to do so if a form of lazyness that the developers cant really do anything about.
I have many times submitted jobs related to helping solve protein folding from within Emacs (shell buffers). It helps a lot to have the editor operating on the shell inputs and outputs.
You really didn't get my point, did you? For new research, protein folding was a random example, you need new terminology which everyone just accepts and uses, it becomes standard.
Emacs sort of tried to do that, failed, and now it's like Australian animals faced with animals from the rest of the world. It will never win, it should adapt.
I think that Emacs solved a lot of important problems before others did. The rest of the world decided to reinvent and rename things, and they popularized some of these things. Emacs held its ground, so now people who transition to Emacs from a different background might be confused. Emacs documents everything thoroughly, so it might take a whole weekend of reading to catch up and be productive. I think that Emacs is worth this extra time. The real number of confusing terminologies or technologies are probably only a dozen or two. And then there are hundreds of common concepts with a powerful implementation in Emacs. And some things that you still can’t do as cleanly with other tools. Especially things you’d need in cutting edge research.
SInce you mentioned "unique" features, Emacs is the only programmable editor which works mostly the same in terminal and GUI mode. You can write extensions (in elisp) which largely dont know about the UI used by the user. So you actually can write UI-independent programs in elisp. I dont know a single tool that got this right. Sure, you're going to tell me that termianl isn't relevant these days, and everyone has moved onto windowing systems. Yes young padawan, that might feel true to you. You will understand one day.
Sure. And because the out-of-the-box is so great:
1. people actually create emacs distributions(!) like spacemacs, doom-emacs, etc.
2. the emacs wiki has https://www.emacswiki.org/emacs/DotEmacsBankruptcy
Emacs is so great out-of-the-box that, unless you're in a terminal, every time you launch it to edit a file, it will take up half its window with a welcome message, until you specifically create a configuration file to disable that. This is particularly frustrating if you just want to use it with its default settings, eg, as root to edit a file.
It's clearly not intended to be reasonable usable without user configuration.
"Slackware is friendly. It's just really picky about who its friends are."
I mean, I'm sure there are like seven, maybe eight, people in the world that think Emacs is great out of the box. Where we run into trouble is that most of those seven or eight people are the ones deciding what Emacs is like out of the box.
> ‘Because this is how rms did it 45 years ago’ is not really a good excuse.
Not only do they use it as an excuse, they think it means Emacs is somehow enlightened. The people that want that can put (setq rms-mode t) in their .emacs and let the rest of us have sane defaults.
I've been using Emacs for more than 20 years, these are all (for the most part) non-issues, brought up by folks who either are new to Emacs or never read the documentation / dived below the surface.
1. Emacs Lisp is great (for the problem domain), exists and works. Common Lisp could work but then given how close Emacs Lisp and CL are, there's no clear benefit, especially with Emacs getting native compilation. Scheme was proposed, some POC code written and failed because nobody was interested. It doesn't fit and fragmenting one of Emacs's greatest strengths (consistent ecosystem of working Emacs Lisp code) is a terrible idea.
2. The Emacs UI core is completely toolkit-agnostic. It doesn't use GTK on Windows. It doesn't use GTK on macOS. You can run _graphical_ Emacs without GTK or any toolkit whatsoever on Linux, and not lose any functionality. Therefore what you write makes no sense (ugly hacks to support a subset of GTK).
3. There are multiple ways to do this. Read up on setting the mark.
4. Threading has nothing to do with TRAMP freezing, bad configuration does. TRAMP documentation (does anyone that bring up these points ever read it?) has multiple sections on improving performance. Check "SSH control master" and "Improving performance of asynchronous remote processes".
5. SVG support is already there and more is on the pipeline.
What I've noticed during my 40 year computing career is that folks get lazier and lazier. Few read manuals / documentation anymore but most are quick to jump to superficial conclusions without any substantial time investment in trying to figure things out. Spoonfed knowledge is the order of the day, and the folks doing the spooning are usually not far from clueless themselves (the blind leading the blind). This leads to generational gaps and rapid propagation of erroneous ideas amidst the newbie masses, very similar to what you laid out.
Emacs mastery requires commitment and time investment in order to understand (at least) the basic models and the trade-offs involved. If that doesn't take place, one can start going down paths that are entirely irrelevant ("Emacs needs threads so that it doesn't freeze!", "Let's use JavaScript so we can do non-blocking IO!", "Let's rewrite Emacs in Rust!")
> What I've noticed in my 40 year computing career is that folks get lazier and lazier. Few read manuals / documentation anymore but most are quick to jump to superficial conclusions without any substantial time investment in trying to figure things out.
The problem is being used to software that "just works".
I've tried out to figure out how to to stuff with Emacs multiple times, but apart from sticking with org-mode for some use cases, I always have up after a while.
I don't see why I should "master Emacs" when there are usually better tools for any given task.
I resisted switching (from vim to emacs) for a long time, but it's just not true that "there are usually better tools for any given task": magit and the other git integrations in emacs are significantly better than the equivalents in VSCode or IntelliJ (anecdotal, but I've never had issues figuring out version control in emacs whereas I've made significant messes trying to use the VC features of VSCode and IntelliJ); the ad-hoc programmability of emacs is second to none (just the other day I whipped up a quick one-off refactoring tool to fill in names missing in the LSP diagnostic errors: other editors might have an equivalent feature, but nothing makes it as easy to combine features in ad-hoc fashions as emacs). notmuch is, so far, the best email interface I've found. And, I could go on: I've occasionally tried switching back to "normal" editors, but each time I find that I'm missing some configuration that was trivial to put together in my emacs configuration and is only available in my new editor if I'm willing to make significant compromises.
Emacs is a tool with an enormous set of available functionality that has been continuously developed for 35 years. Moreover, its major strength is its programmable and nearly infinitely-extensible nature.
And yet, it does "just work", from the moment you first run it -no previous experience needed- it does present you with a familiar "editor skin". It does offer you an interactive tutorial. It does come with comprehensive offline documentation. It does come with the best interactive querying and documentation capabilities of any software system in wide-use today.
So, taking all of that into account, when you say "just works", I read "I don't want to spend any time whatsoever to learn 35 years of features and a software system that is by far the most user-empowering in existence today". Your loss.
:facepalm:
Yeah, my 8 years old niece will be taught "Informatics" in the school. Starting in a few days, actually. I'm sure she will enjoy Emacs over Notepad, since Notepad doesn't have any interactive tutorial.
> It does come with comprehensive offline documentation.
To avoid using precisely that, some years ago, I created myself a little extension of the engine-mode which opens up a browser and searches on the internet using a proper search engine. Here's the code:
https://github.com/Bost/dotfiles/blob/c262e4dd7c5a498ce5d75c...
Enjoy
> It does come with the best interactive querying and documentation capabilities of any software system in wide-use today.
I managed to learn how to write my own plugins, macros, spacemacs core extensions, etc. I hope one day I'll learn how to use the emacs interactive documentation, too. Eventually.
Emacs is definitely not a SW to use if you're not going to read the docs. There's no good argument that Emacs should be, especially given what you say:
> I don't see why I should "master Emacs" when there are usually better tools for any given task.
I use Emacs for all kinds of things - not just programming. If I pick any one, there's definitely a better tool out there. Emacs's strength is the ability to tie it all together. If all a person wants is a good text editor, I would not recommend Emacs to them. Emacs is one of those things where you get more out of it the more you invest in it.
And it's totally reasonable to decide not to invest in it.
I guess that's what might be the difficulty for newcomers: having an idea of what exactly I could use Emacs for that justifies the high upfront investment compared to other tools with a more familiar UI.
Doom Emacs and other distros are great because they allow to just dive in with minimal configuration effort and sensible defaults. Without it, I certainly wouldn't have started using org-mode.
It shouldn't be necessary to learn a programming language and spend hours with the Emacs documentation just to be able to use some of the great packages like org or magit.
> It shouldn't be necessary to learn a programming language and spend hours with the Emacs documentation just to be able to use some of the great packages like org or magit.
It isn't. You could just go through the included tutorial for Emacs, and watch a tutorial for org, and you'll immediately be productive in org.
And you definitely don't need to learn elisp. I was a power user for almost a decade before I learned elisp. The most I could do was use setq.
The point of my comment was that one can easily be productive in Emacs, but if you want to do things that set Emacs apart from other tools, you'll need to go further and read more docs. Someone could learn just the basics and write documents/code with Emacs fairly quickly. But those people will continually ask "What's the point - I could just use an IDE which follows semantics I'm used to."
Doom/Spacemacs are great - just not for everyone. It's good to have them around, and it's good to have better defaults in vanilla Emacs. However, there are a lot of config choices they made that I guarantee would have turned me away from them as a newbie.[1] They are a lot more opinionated than vanilla Emacs, and would likely turn off as many new users as they will attract.
But it's good to have more options.
[1] For one, I could never wrap my head around vi keybindings - and I tried them before I tried Emacs.
2. It makes perfect sense if you actually learn how Emacs works. It provides superficial elements like GTK-look-and-feel (scrollbars, menubars). Most Emacs experts disable all of these anyway, thus nothing of value is lost. On the other hand, toolkit-less Emacs tends to be a lot more stable. That was definitely the case for GTK since it had well-known bugs that the GTK developers refused to fix that would crash Emacs. I suggest you compile graphical Emacs on Linux without any toolkit (or with Athena/Lucid/Motif) to see for yourself.
3. Because there are trade-offs involved and the (informed) user should be responsible for enabling them.
The fact there are known workarounds for certain problems shouldn't prevent us improving and fixing the underlying causes (in a step-by-step, backwards-compatible way).
With that said, I'd rather not see Emacs go all-in on threads or GTK, since they generally feel like WorseIsBetter anti-patterns:
- GTK 2 seemed OK, but unusable for me due to the 'display disconnection' bug. GTK 3 is full of red flags: a constantly moving target, little thought given to third-party applications, pretty much killed off third-party theming, etc.
- Threading is famously error-prone, which is completely unnecessary for high-level languages like Emacs Lisp. Co-routines, async/await macros, delimited continuations; even an actor model would all seem like better fits.
GTK3 is actually feature frozen, it's not a moving target. Development has moved to GTK4. Also, it has always supported third party themes, however the convention is that they were always considered unsupported because they can break apps.
Similar age, back in 1995 XEmacs was my refuge, because most UNIX world was foreign territory for IDEs and developer editors like Ultraedit.
With the way UNIX landscape evolved, I seldom use it, although the last time I used it in anger was around 2006, the muscle memory is still there, but really, the IDEs I missed in 1995 are now available everywhere.
Be aware that this are comments from people who use emacs. It does'nt mean that implementing these wishes will also lead to more users coming to emacs. Even the low hanging fruits from the article are barely something that will bring in new users.
Though, distributions like spacemacs and doom-emacs have shown that they are bait working well to get new users. Investing more in that directions should pay out to some degree.
There are a good number of Emacs users who also use a Lisp dialect such as Scheme for their day-to-day work. Emacs Lisp has enough small, slightly strange differences from more mainstream Lisps that I can imagine that being kind of frustrating.
For myself I think that Emacs Lisp is a pretty good language for configuring a text editor. A lot of its warts actually make it easy to use in that context, in my opinion. Personally I wouldn't mind moving closer to Scheme or CL. Though I wouldn't want to lose "special" variables (with dynamic binding) no matter what happens -- they're a key tool in tweaking behavior to get it just how you want. But for people who are trying to build packages, especially large ones on the order of Org or Magit, I can see having a more, let's say production code oriented language, being a nice prospect.
No, I mean emacs was designed for terminals. The whole GUI is build ontop of this and is suffering from it. Is pure-gtk changing this and decouple from the terminal-design or still working with it, replicating the same hacks just in a different GUI?
Terminals work with characters, meaning, lines, columns, fontsize. GUIs usually are working with pixel, meaning x/y-coordinates and free sizes.
In case of emacs this means there is a bunch of hacks to translate pixel-coordinates to line/column-coordinates. This often are working well enouhg, but sometimes not. For example, with my emacs there is always a free space at the bottom when maximising the window, Resizing the window also works in terms of lines, not pixels. Positioning of completion-dialogs is linked to chars, not the pixel-coordinates of a the word which in certain cases get's ugly.
It's overall not what I would call a hard issue, but still ugly. But it also kinda limits what you could do with Emacs in GUI-world. As Emacs has no understanding of z-axis, there are overlapping widgets and free-positioning of elements outside the text-flow.
An additionally, it seems the too many laysers and additional complexity has some speed-impact in GUIs which the terminal-version has not.
I've seen all these before and it makes me wonder why someone doesn't just make a different version of emacsen like guile-emacs. There must be a lot of inertia behind emacs and substantial amount of development effort to make all these changes that keeps competitors to gnu emacs from progressing to replace it.
Because of GNU Emacs biggest strenght, which is also it's biggest flaw: the mountains of existing code. Any new emacs must support what emacs already offers. And this means not just to be able to run the code, but to also support the huge amount of special and exotic features that Emacs offers. Guile-emacs for example has a pretty long history on fighting emacs-strings and it's special features.
There is the general believe that users don't wanna change from emacs away and any new emacs should be ~100% compatible to old emacs. But history has shown, people will not settle with inferiour clones. So many work will be neccessary, whatever someone will build to replace emacs.
Regarding 3. Ability to scroll without bringing point along.
You can duplicate the buffer side by side with the original buffer and in each window point will be at a different location. This is fundamentally just better than such a peek mode as you can see two different segments of the same file side by side. If you do want to peek and return you can use goto-last-change to return to where you were last typing. In evil this is bound to g; no idea about a binding in plain emacs but nothing is stopping you from using and binding such a thing.
You can also use marks in evil m[a-z] to set a mark '[a-z] to go back to that mark. so for example ma 'a to go back.
Consider the alternative. Since you don't want scroll to always leave point behind you must have a special binding to enter peek mode and thereafter you scroll as normal. Then one of two things has to happen. Either you decide point really ought to be here now and you have to hit a key combo bound to end-peek-at-current-location or another key bound to end-peek-return-to-point. I would suggest escape/q for end-peek-return-to-point and return for end-peek-at-current-location. You can also do end-peek-return-to-point if you just start typing obviating the need for an additional binding but I think this would be a little weird because there would be a slight hitch while it pops back to prior location.
The biggest defect with this compared to goto-last-change is that it is ironically given the alternative being part of evil modal. You have to decide to use peek ahead of time and then you have to remember you are in that mode and do something to get out of it should you decide you actually want to do something different like exit with point at the new location. With goto-last-change you don't have to decide ahead of time you can simply decide to go back after the fact without needing to attend to any state in between.
Multiple windows on the same file and marks require attention ahead of time but are far more general and powerful than peeking.
Sometimes what people want and what is most useful are different things. Fortunately Emacs is simple enough and powerful enough for you to implement peek mode trivially if you like but I don't think it would be worth using compared to the alternatives. Logically you could implement it by remembering present point and making local bindings to go back to prior point example esc to go back enter to remove local binding to esc.
>You can duplicate the buffer side by side with the original buffer and in each window point will be at a different location.
I actually attempted that last night. It doesn't work unless you disable completion frameworks like company/LSP because as soon as a completion event triggers, both buffers snap to the completion location.
this is very odd. I both routinely have duplicate buffers visiting the same file and use LSP with company mode. I have never seen the snap effect you are describing. Why would completion trigger in both buffers? Maybe it is company vs ac-mode or some other completion system?
I was unable to reproduce this just now in emacs 26.3 using company/tide. I've been thinking about moving from tide to LSP, but that bug would drive me crazy so maybe I should wait for it to be fixed.
Just tested this with company in a clojure buffer and did not observe this. I would suggest that something else responsible for the effect. Do you have any idea what causes this?
To me this seems like the answer. We don’t need to change the way emacs works, we just need a standard way to do this that is familiar to people coming at emacs from other environments.
Well, yes, it's Emacs, we can probably do anything we can imagine, but that's beside the point. This particular behavior is stupidly annoying for both newbies and old-timers.
Even if Emacs works internally with the concept of a "point" that is always set to a position in the visible part of a window, text editors evolved over time to adopt the concept of a "cursor" that always stays in place unless the user moves it. It's about time Emacs adopts the concept too, and sets a well-thought default behavior for it.
> Even if Emacs works internally with the concept of a "point" that is always set to a position in the visible part of a window, text editors evolved over time to adopt the concept of a "cursor" that always stays in place unless the user moves it. It's about time Emacs adopts the concept too, and sets a well-thought default behavior for it.
I'm a Vim user, not an Emacs user, which likely means my opinion isn't worth much; but I think the point I'm about to make is the same.
I use Vim because I like its user interaction paradigm. It is badly out of sync with modern text-editing paradigms, and that's fine. I would be _very_ upset if it started updating to stay relevant. If someone wants an editor that behaves more like modern editors, then they can use a modern editor; and, if they want the best of both worlds, then they can fork Vim and modify it (and there are successful projects doing exactly that). There's no need to modify core Vim to attract new users while alienating old ones.
Establishing better defaults in an application is never a bad move. Power users can still customize things to make them behave in whatever way they want, and newbies benefit from a better default setup. This doesn't mean dumbing down the UX. The goal is to provide a better ramp from newbie to power user, so that newcomers can quickly benefit from some of the cool features without having to study for a week before being able to do the most basic things.
This is how Vim does it, actually. If you keep it in insert mode, it's like a basic text editor, usually with the terminal itself taking care of basic copy-paste. Eventually, people begin dropping out to normal mode to use more and more commands.
I find this kind of thinking interesting. Like Emacs is a bold child that needs to shape up … rather than a conintiually evolving codebase developed by enthusiasts. If it doesn’t do “this thing” it’s probably because it doesn’t need to. There’s probably better ways to do this that experienced users are comfortable with. For the newbies then you only need workarounds to make them comfortable, such as that which I described.
I’m fairly positive 90% of any feature in emacs being unchanged in decades is directly attributable to backwards-compatibility than anything else. With how invasive emac scripts can be, it’s difficult to imagine anything to be changed without forcing the question: is it worth breaking userspace for this?
I don’t think the defaults are good — I suspect they’re stuck.
Why would Emacs turn down the possibility of adopting new user interaction concepts? It's not like we have to choose between "point" and "cursor", both concepts can coexist.
I find it funny to characterize Emacs as "evolving". There's been a lot of internal work, and some new features over the years, but almost all of the evolution happens on the Emacs ecosystem, not in Emacs itself. Core Emacs isn't evolving. Default Emacs is nothing more than a blank slate. And there's no clear, easy way to go from "blank slate" to "useful tool". It's either opting for one of the big config packages such as Spacemacs or Doom Emacs, or keeping Emacs as an Elisp playground (and I'd argue that an Elisp playground isn't a tool anymore, it becomes a goal in itself before it can be useful as a tool).
If you are thinking of a mouse oriented text editing gui where one scrolls with the scroll wheel and then clicks somewhere and starts typing from there this might make perfect sense. In fact you can of course use Emacs like that if you prefer but for keyboard oriented operation it would be absolutely odd if operations that moved the view didn't also move point and in fact other functionality depends on this. Presumably making visual point from internal point different would complexity and work and I have no idea to what end this work would be.
It would be equally weird if scrolling with a mouse wheel worked differently than scrolling with page down for example. In fact in many applications I now realize it does work differently. It's likely that I and many others are not likely to notice because when we do scroll with the scroll wheel in an editable field or document we immediately follow a series of scroll operations with a click in the appropriate location where we intend to insert text. That is to say people are unlikely to exploit the fact that visual point and point are different as a deliberate feature because its awkward. It's spacebar heating.
I would also venture to guess people are vastly more likely to scroll documents in emacs via keys compared to the scroll wheel in part because mouse scrolling emacs isn't awesome. That is a better thing to improve.
1. Switch out Elisp for a Common Lisp or Scheme
2. Update the way Emacs Ui Core so it used standard GTK or something better. (The current implementation uses a lot of ugly hacks to support a subset of GTK)
3. Ability to scroll without bringing point along with me so I can quickly check something off screen then just continue typing where I left off.
4. Improve threading so that things like TRAMP didn’t freeze when you were connecting
5. Fast/Arbitrary graphics support
I think for most Emacs users it’s a performance thing. Though the improvements to the GUI code would go a long way to making it easier to make Emacs be more user friendly.
In terms of this article. I think all of this is possible in a separate distribution of Emacs right now. Emacs will never turn on most of these things by default. But maybe if a version of Emacs that makes these changes becomes wildly popular, the current maintainers would be more amenable to it.
https://old.reddit.com/r/emacs/comments/padv22/if_you_could_...