Oddly, I think you will make Emacs appealing to users when you start asserting it is appealing to users. Few changes really needed. Just stop intimidating people before they get involved.
To some degree, I agree. I've been playing with Doom Emacs[1] recently and it has been pretty smooth, the configuration and such more so than my regular Vim setup.
I tend to agree, too. It is really no worse than any other complex application, and far better documented than most.
An an occasional user of both Excel and Emacs (mainly a vi guy), I waste at least as much time figuring out where "that tool" in Excel went or how to get in to one of the weird graph editing modes as I do with the more obscure Emacs features I use sometimes.
My experience with Emacs has been a steady upward trajectory, gaining understanding and access to functionality. I now use CIDER and TRAMP every working day, and no true equivalent exists for any other editor (though many are catching up to CIDER, due to Clojure being the better lisp!).
The biggest problems with Emacs, to me, are the rendering performance, the lack of sufficient threading, the default keyboard-accessible windowing commands, and Elisp being unergonomic and sad.
The course I'd chart for an ideal Emacs would be rendering with something like Alacritty†, some default windowing commands similar to tmux, and phasing out Elisp in favour of a Clojure dialect; the last bit would help a lot with introducing some basic sources of concurrency.
† Plus smooth scrolling surfaces, since a text editor generally does not have enough surfaces that the memory overhead of tiled surfaces is a serious issue like it is for general-purpose renderers like web browsers.
At least when I've written elisp, the default datastructures have involved a lot of work to construct and manipulate, and when you do it right, the ones you've chosen for convenience may perform so poorly that you have to go back and change them to get your program to complete in time.
Namespaces for vars and functions being not a language feature is inconvenient. Unless you are using fakespace or intern-symbol (it seems hardly anyone does), every symbol in your program needs to include its namespace information in order to avoid it being accidentally invoked by somebody else, or accidentally convincing somebody that it's part of the base distribution.
In Clojure, it's many little things:
Keywords are callable, allowing you to evaluate a keyword on an associative collection like hash-map, or traverse, in an obvious and intuitive way, into a nested associative structure with the threading macros "->" and "->>".
The default data structures are fast (for what they are) and hard to misuse: unless you ask politely, you are not going to mutate something your function was passed passed without noticing. seq, the interface for sequences (vectors, lists, pairs from an associative structure), pairs well with destructuring in let and macros/syntax that does binding.
Things like 'let' don't use more parentheses than necessary, which has a greater impact on readability than you'd think. The use of vector syntax for bindings rather than list syntax adds a little bit of syntactic texture that makes reading programs more ergonomic.
I think Clojure may not be as unfamiliar as it seems at first to a person who's written other lisps before, but I have yet to meet somebody who prefers the experience of writing Scheme or Common Lisp to Clojure; nor anyone who prefers Elisp to Common Lisp.
Likely a polar opposite of Clojure, but there is an attempt to add Guile (a Scheme dialect) to Emacs[1] which aims to provides a faster Elisp backend, and support for using Scheme to program Emacs.
While elisp has lots of warts and weirdnesses stemming from ages long ago, I find it quite suited for its task as an editor scripting language.
For instance, the global namespace is great to play with and learn commands in the scratch buffer.
Also the custom datastructures and generally the emacs lisp abstractions around editing are a joy to use.
I agree though that the rendering is too old fashioned. I'd love for Emacs to get smooth, animated scrolling instead of that tty-esque line-by-line movement of the text. That really makes it hard to keep track when scrolling throught large documents.
Many years ago I implemented JEmacs (http://jemacs.sourceforge.net/) - a proof-of-concept (i.e. very incomplete) port of Emacs to the Kawa framework. Kawa is primarily an implementation of a nice if-I-say-it-myself dialect of Scheme compiling to the Java VM, but it can be used to compile other languages - specifically Emacs Lisp. JEmacs is long dead but Kawa (https://www.gnu.org/software/kawa/) is still actively used and maintained. It has a number of niceties and ideas worth checking out.
I like to tell the story of how secretaries in the 70s learned how to use and customize Multics Emacs with Emacs Lisp; they were told they were simply customizing their editor, not programming it.
That's the really cool thing about Emacs. The only difference between "simple variable settings" and "proper lisp programs" is a difference of scale, not a difference of kind. Variable settings are just as much code as anything else in Emacs.
Indeed. (+ 1 2) is a "proper Lisp program". By having all that power available from the start, users can use as much or as little as they need and shape the tool on the fly as they work with it. It's the difference between an extensible text editor and a completely malleable one.
> I think you will make Emacs appealing to users when you start asserting it is appealing to users
I've worked with a lot of Emacs fans but everyone describes it as having a hefty learning curve. If you tell people it's appealing and the first experience is unpleasant, all you're going to do is convince them that you aren't a reliable source of advice. I think it would be much better to focus on easing that initial stage and explaining it a powerful tool which requires some up-front investment.
Exactly. Whenever a new developer asks what editor I use, I emphasize that while I use emacs, it has a huge learning curve. It has different conventions than any other text editor, because it predates those conventions.
Remember that Emacs is competing with things like Visual Studio Code, Atom, Sublime Text, etc. If you tell people that it's easy they're going to try it, bounce off, and conclude you have no idea what you're talking about. If, instead, you tell them what you like about it more than those others they might find they agree with you.
Speaking as someone that has bounced off the likes of notepad... I think you are overstating the case.
I'm not saying to merely claim it and call it a day. I'm saying claim it while showing people how to use it. Make it a dialog that doesn't begin with, our way is harder. It isn't harder. Just different.
I would like to understand why vim does not seem to have this problem? I guess as stated below, it's just they way it is marketed. Because the way I see it, emacs is much easier to start out with than vim.
If I start emacs, I can navigate around the text with the arrow keys, the way I would expect from most other text entry systems. Then I can just type stuff. I can click at points in the text to navigate there, just like in notepad or anywhere else.
OTOH in vim it is nothing like that. Nothing is even remotely familiar. Yet there are much more vim users than emacs users. So I don't buy it that the learning curve is the problem.
> I would like to understand why vim does not seem to have this problem?
That’s seriously begging the question — I mean, there’s a pretty popular running joke about quitting vim and it’s been many years since I’ve heard any recommend it as easy to get started with. In the 90s people suggested it due to Emacs hitting memory constraints but most CPUs now have more cache now than those computers had.
I know, people are joking about how it's not usable. But still there are a lot of people using it! So maybe it's not actually an issue for adoption, so I wonder why this argument comes up with emacs then, which, in my opinion, is OOTB not as weird as vim for someone unfamiliar with either of them.
Getting started with Emacs and having basic skills (load, save, cut, copy, paste, search) is WAY faster than with vi. I don't use more than a tiny fraction of emacs's capabilities and likely never will, but the initial part of the learning curve is way easier than it is with something like vi.
But emacs is not against vi. When I taught a class where I started by introducing emacs, the first question I got was how to make it have this color text and that hentai page background.
I generally use aquamacs when I need emacs these days (especially since Catalina no longer includes the terminal-based emacs by default). It offers a lot of customizations through menus for the appearance, not to mention that it supports standard cmd-whatever shortcuts for the basic functionality.
> "Perhaps we should implement a mode that puts cosmetics on Emacs so it will appeal to those who judge by the surface of things."
I'm sorry to react to first quote, but as I kept reading I kept coming back to it. My thoughts on that : how you present yourself is how you want (and are going) to be judged.
In general I think Emacs has been user-hostile, as said here, just by its terminology. Nobody outside a minority of devs (a minority even among programmers) refers to Ctrl+c as C-c.
> Yes, make Emacs appealing and user friendly. But don't forget that a masterful tool in the end requires mastery, which can't come for free.
And the old "I have suffered therefore the others have to suffer".
> Nobody outside a minority of devs refers to Ctrl+c as C-c.
First, C-c is not Ctrl + c; second, it really helps to use compact notation when you read a lot of keybindings; and third, this is approximately the most minor complication in the learning curve of Emacs (otherwise nobody would learn vim, with its insane key mappings and invisible mode transitions).
> Exactly what I mean. It is insane. I can't get it straight. I really tried years ago. But it is plain and simple stupid.
No, you're just being ignorant, and not reading when people try to answer your questions.
> Abbreviation is only useful when writing for speed. When writing for reading, don't use them.
It's not an abbreviation, it's a different symbol. C is not Ctrl.
The software has some “baggage”, being the heir to a 40+ year legacy, but the problems you're ragging on are so shallow that it just tells me you never tried. Why would anyone want to continue holding the hand of somebody who isn't even trying?
Emacs is full of excellent documentation, the first thing it tells you when you open it is how to find the documentation, and if you have a mouse you can just click it; if you opened it and decided not to read the intro, but somehow a lot of other people are using it productively, maybe the main problem lies with you.
If you're looking for a piece of software that'll give you some sort of religious aesthetic orgasm just looking at it; sure, you'll be let down. If you were trying to get something done and approaching it honestly, these would not be your complaints about Emacs; trust me that there's a lot wrong with it. Having its own slightly different keybinding notation is like... number five thousand on the long list of actual issues with any honest attempt to be productive with Emacs.
And yet I could get a few things done in vim in a few minutes, and much more than that in a few weeks. And I choose not to use vim. And yet you said vim has insane key mapping but more people somehow use vim than emacs. Some things are not adding up. Emacs has excellent documentation but somehow very few people are able to use it. Some things are not adding up.
Emacs interface and community mannerisms _are_ user-hostile. As demonstrated by history.
There are lots of things that seem daunting at first and unforgiving to the impatient beginner: chess, surfing, martial arts, drawing... it doesn't mean that any of those are user-hostile, it just means that those that want to learn and master it will need to develop a certain discipline.
If you don't want that, fine. But what is the point of going around and saying that those who do enjoy these things are stupid?
I did not say they are stupid. I'm saying some communities build on pseudo-elitism. It's not stupid to enjoy using a text editor. It's stupid to argue that because it's hard to use (and hard to master) "you're just not getting it".
I think the expirement is over and conclusions can be drawn : emacs represent a tiny proportion of text editor's users, not because of a lack of features (is there's one thing missing it won't be for long), but because of what it is and the people and community around it.
> It's stupid to argue that because it's hard to use (and hard to master) "you're just not getting it".
It is also a bad misrepresentation of the point made by the person that you originally quoted.
Let me try an analogy: emacs is Olympic-sized pool, 50m long, 5m deep, with a 10m jump platform. It has been in use for decades by all kinds of people. Some new people see some amazing swimmers and divers using that pool and want to join. Problem is, they also don't know how to dive and are still learning to swim so they ask for a nice ladder on the corner and they want the pool to have one end shallow enough for people to stand on.
The developer is basically saying: yeah, getting in there is intimidating at first and we can do some improvements to help beginners, but we also need to find a way to get those beginners to get into the training program, train harder and dedicate themselves to diving, otherwise it would just be a waste of time and resources. Oh, and we also need to keep in mind that none of these changes should affect the people that are already training here for years.
> I'm saying some communities build on pseudo-elitism.
I'm not saying that Emacs users are better than you, I'm saying that you lack the experience to judge the value of Emacs; and that your lack of experience makes your assessments of Emacs basically too shallow to contribute meaningfully: in short, you don't know enough about Emacs to tell if your dismissal of it was premature, or if the things that turned you off were just the unfamiliar tail end of a coherent system.
It should be obvious that there are many many people who have spent more time actually using Emacs than you, and almost none of them by force or by fiat: literally nobody asked me to use Emacs, nobody started me using it, I received little or no assistance in learning it, I was mocked for using it as a teenager, and I spent most of my time with Emacs on teams of droves of people who do not use Emacs and evangelize other editors. At the outset, I simply wanted to try it, and I gave it a fair shake; I continued to use it because paid off for me.
The fact that people willingly start, and continue, using Emacs of their own volition with no external help or encouragement, should tell you that there are merits to the program that outweigh the things that turned you off before you gained any meaningful understanding.
C is an abbreviation for <Control>. You can map pretty much any key to any other key, that’s neither here nor there. M is for meta, s is for super, S is for shift, A is for alt, H is for hyper.
My control key is mapped at the window manager and terminal level. As far as emacs is concerned it’s control. If I map my R key to emit a control key code... C is still an abbreviation for control.
No M is for meta. These names predate X let alone XFree86 by many years. The names don’t even come from a Unix system. Even GNU emacs predates XFree86 by 6 years.
Your writing implies that Emacs is something like the notepad of Ubuntu. But it’s history is much more extensive than that—- which happens to be one of its unique selling points.
Anyway the point regardless of historical context, is that for all sensible people, that capital C is being used as an abbreviation for the word Control. You’re just being a prat correcting people. You’re not even technically correct, you’re just wrong.
Those aren't "Apple's glyphs", they're part of the ISO/IEC 9995 standard for common keyboard layouts. https://en.wikipedia.org/wiki/ISO/IEC_9995 Perhaps Emacs and the Linux desktop should start using these characters by default, seeing as they now have good Unicode support.
Emacs' notation for keybindings uses C for indicating the Ctrl/Cmd key and M for the Meta (alt).
Things like C-c C-v are chords. <Ctrl+c> and <Ctrl+v>.
I might be wrong, but I believe that the reason that parent commenter said that "C is not Ctrl" is due to the fact that you can map these keys to any where you want. Most emacs and lispers prefer to have C key bound to caps lock.
> I might be wrong, but I believe that the reason that parent commenter said that "C is not Ctrl" is due to the fact that you can map these keys to any where you want. Most emacs and lispers prefer to have C key bound to caps lock.
Yeah, but it's still a control key. I mean, xev literally registers "Control_L" when I press the key that is physically labeled "Caps Lock".
C-c is a chord (two keys pressed at once); C-c C-v is a chord progression (first one chord, then the other), more often referred as a sequence in this context.
Were this an actual conversation where someone wants to start with emacs, I would be showing the sequences (as in "see, Ctrl-x and Ctrl-f gives you a prompt to write a file. Now try Ctrl-x and Ctrl-s...") and I would show the part of emacs that gives the user feedback about the command.
Discussions about terminology are totally secondary, and honestly, I was just trying to find a polite way to show that I don't want to get into an argument about terminology.
> And the old "I have suffered therefore the others have to suffer".
Actually, its an extremely important point. Tools which optimise for the professional are better than those which do so for the noob. Whenever you can achieve both, do so, but never side with the beginner otherwise. People should learn their tools, and they shouldn't be beginners for long, so making things "friendly" at the cost of rewarding expertise is poor design.
This is absolutely true. However, if you can make a tool more learnable for new users without sacrificing its optimization for power users, you should. One way to do that is to not gratuitously invent new terms, and to use terms people are familiar with.
Using conventions like "M-x" throughout the documentation, even with a note at the front of the manual that "We refer to Alt as Meta for historical reasons.", is needlessly baroque. Worse yet, maintaining a distinction that those aren't effectively the same thing for almost all users is needlessly unhelpful. (Yes, it's possible to make Alt and Meta different keys under X with use of modifier maps. That explanation belongs in an "advanced keybindings" chapter late in the documentation.)
It's certainly possible to learn that, and a hundred other gratuitous weirdnesses, but they don't actually add value that justifies imposing that weirdness on every user.
There's some bad stuff in emacs but to concern yourself with Meta as opposed to M- is plain silly.
> if you can make a tool more learnable for new users without sacrificing its optimization for power users, you should
Yes, but it's incredibly difficult and frankly the emacs devs have enough to do (and they do it well), and UI design is a very different skillset from programming. Frankly the learning curve for emacs is not going to improve, muchas we both might wish it.
The biggest problem is people want the benefits of freely downloadable software but mainly aren't prepared to give anything back. Go and assist with emacs or some other project.
> The biggest problem is people want the benefits of freely downloadable software but mainly aren't prepared to give anything back. Go and assist with emacs or some other project.
I don't really buy this line of argument in general, but I think Josh is a particularly poor candidate to pull rank on because they don't contribute to open source. I don't know Josh, but I recognize his name from his open source contributions.
If you don't recognize Josh's name, you can get an idea of some of what he's done from his website, which is linked in his bio: https://joshtriplett.org/
> I work on Linux, primarily on the RCU subsystem and on Sparse-related code. I maintain the rcutorture test module.
> I co-maintain the X C Binding (XCB). I developed the XML-XCB format to describe the X Window System protocol. I also work on other Xorg projects on Freedesktop.org.
> I maintained the Sparse semantic parser and static analysis tool for C for several years, before passing it on to Christopher Li.
> I maintain several packages in the Debian project.
Consider me very regretful indeed. Most people who moan seem to have nothing to contribute, well I got it very wrong this time. Apologies to @JoshTriplett if you're reading this, and Ill check out your stuff tomorrow.
Ah shit, I recognise your name too. I've just been spanked by Dan Luu. This has not been a good night.
I appreciate the sentiment. I would gently suggest focusing the regret on the message rather than the recipient; it wouldn't have been better if written to a novice user.
Right. I see this point ignored very frequently (sometimes because it's obvious and sometimes because people are being dumb).
A lot of the things that would make emacs more like other editors are extremely difficult to retrofit. I expect there is still SOME low-hanging fruit, but a lot of the low-hanging fruit has already been picked, and a lot of the remaining changes that people would like are a lot of work.
Let's discuss that. Emacs is so flexible it should be possible to do anything. Binding cut/copy/paste functionality to the conventional keys would be trivial. A few rebound key bindings, not a problem, so you're getting at something larger; what is it?
BTW the current key bindings are so good because I can do a lot without my hands leaving the keyboard, or even moving off the home keys. That was the very point of choosing them originally AFAIK. I recall learning these new keys many years ago, it was surprisingly fast and when I'd learnt them, amazingly quick to sink into muscle memory.
Unfortunately the rest of the software world settled on keybindings for cut and copy that generate almost the greatest possible pain for Emacs to migrate to them. C-c and C-x are used for dozens of the most important commands. It's technically feasible, but switching would be hard and existing users would be really upset.
I assure you I'd never propose to change emacs bindings at all, merely have a switchable alternate set. I think that would be possible? But even if you did so, there's too much else, far deeper that couldn't be amended. I think we agree it's not a credible proposition. I suspect emacs' enormous toolkit can't be exposed consistently without making it inconsistent. I can live with emacs as it is, very happily.
I think you misunderstood. Control, alt, meta, hyper, and super are (at least on my current OS) distinct modifiers. There are also keys bearing some of those names on most keyboards which makes things confusing to talk about.
Each modifier can be mapped to any physical key. For example, I'm one of those control as caps lock people you mentioned. I then have hyper on the left control key, alt and meta (yes both) on the left alt key, level 3 on the right alt key, and compose on the right control key.
Unfortunately I didn't notice your reply earlier (the consequence of being productive).
Rereading my previous comment I've realized there are some slight inaccuracies - keybindings are conceptually a bit complicated (at least under the historical X11 model). My Alt keycap actually just produces the corresponding Alt keysym, which maps to mod1. My confusion was due to the Meta keysym also mapping to mod1 (this is the default configuration) even though no key on my keyboard is currently configured to emit it. I set everything up quite a while ago and then forgot some of the details.
* Caps Lock -> Control: This is simply more comfortable for frequent use, particularly in combination with the Vi directional keybindings (hjkl).
* Right Alt -> Level 3: AKA AltGr, this is useful for entering common Unicode characters.
* Right Control -> Compose: Useful for a number of other Unicode operations. I don't seem to make much use of it in practice though.
* Left Control -> Hyper (-> mod3): I had a free key. This gives me an extra modifier for use with things like my window manager that's pretty much guaranteed not to conflict.
* Shift + Space -> Underscore: Makes C programming _way_ nicer.
* AltGr + Space -> Nonbreaking Space: I don't actually remember why I configured this one. I never use it.
* Shift + Shift (ie left & right) -> Caps Lock: I don't actually use it, but this way it's still available.
I've never seen a keyboard with hyper or super. I doubt many people have, since they were only present on hardware obsoleted decades ago. Meta, aka the windows key on most PC keyboard, is usually present, but most people wouldn't know its name. On Windows, it's not even usefully bindable since Windows uses various shortcuts for it by default. On Linux, it's not bound to Meta by default by most distributions. So for the vast majority of people, it's just Alt.
I don't think Emacs has done itself any favours by using obscure and non-standard terminology based upon machines from the '70s which few people have heard of, let alone experienced. For the vast, vast majority of us, we all have bog-standard PC or Mac keyboards, and have done for the past 30+ years. It would have been in everyone's interest to standardise on terminology and keybindings which were immediately understandable and usable by all.
Given that every other application uses the standard terminology and keybindings, and that I don't see much in the way of compelling advantage to keeping the non-standard bindings other than habit, I think preserving backward compatibility for four decades was laudable but misguided.
Neither have I outside of photographs! The trouble is that they did exist previously and X11 settled on an abstracted model that supports 5 modifiers (in addition to control, shift, and lock). You have to bear in mind that Emacs can't just stop supporting certain (now defunct to the mainstream) modifiers as many users have setups which depend on them.
I suppose that cosmetically they could update the documentation by changing M- to A- or Alt- or something. Would it really make a difference though?
Aside: Not meaning to be pedantic, but at least under X11 Super is the "Windows Key" and Meta doesn't exist by default. I just checked and (on my machine) the keycap with the Windows logo maps to X11 keycode 133 (hardware specific) which produces keysym Super_L at both levels 1 and 3 which in turn maps to mod4.
I think maybe you're over-emphasizing the problem with this terminology. When I first started learning Emacs it took me all of 5 minutes to get used to the new terms, it isn't that hard. Maybe there's an argument for the lack of value of using older terminology, but again, I think this problem is overblown.
I'm not trying to say this is the most critical problem; I'm saying it's one example of many, and it spends a lot of "weirdness budget" without necessarily providing value in exchange. "kill/yank" is another example, and there are many more where those come from; the volume of them creates a "thousand papercuts" problem.
In the Rust language design, we're careful about what we spend our "weirdness budget" on. We've already spent a fair bit of it on terms related to ownership and borrowing, because those are fundamental and central to the language. We spent some on having a one-character '?' operator for error-checking, because error-checking occurs so often. But we're not going to gratuitously introduce new vocabulary for existing concepts that already have a name people would be more familiar with, and we're extremely hesitant to introduce gratuitous syntax abbreviations just so people can type a little less, because they'd be harder to read and understand.
I agree that a lot of things are weird and could be modernized.
That said, as someone who very slowly got into Emacs and now am full on into it, all this weirdness slowly became more of a an, oh this actually makes a lot of sense, and, you know what, I might like it better.
I still find it weird for a frame to be a window and a window a frame. But logically, I think the Emacs names make more sense. The thing with a frame is a frame, and the sections within it are the windows. I wouldn't mind if it was renamed frame to window and window to panes tough.
Similarly, C-c and M-m used to confuse me a lot. But now I find them way nicer, why have to type all of Ctrl and alt. Also on Mac alt is called command, so having a Meta as a more generic name for the key kind of works.
Kill was weird to me, until I realized kill and delete both exist, but behave differently. There's a kill-ring, text that is killed go in it, text that is deleted doesn't. When you program extensions this is a very important distinction. You don't want programmatic edits to all go in the kill ring and polute it.
Would it be nicer if the more common user used one, which is kill, be named delete which is more familiar to people maybe.
Like I said, I wouldn't mind someone making a big refactor of it all and renaming everything to be less weird to modern times, but I think as you learn those "weirdness" they stop being weird.
Basically, I mean there's a big difference between a quirk, and just something you're not familiar with. I think Emacs names are mostly unfamiliar.
Emacs also has real quirks though, and I think those are more important to address. Like there's a lot of legacy cruft, having to still support working on defunct terminals, and all kind of stuff. Like ESC being a weird Meta key because of terminals that don't support meta. Or the entire UX which is crap by default.
"M = Alt", "C = Control" is such a trivial thing to remember, yet it is brought up as a critical emacs deficiency every time. Why isn't this argument brought up in every Mac/PC discussion, or Xbox versus playstation?
You can absolutely do both.
In VSCode, if I don't know how to perform an action, I just hit Ctrl+Shift+P and the fuzzy search panel with all the possible action shows up, with the associated keyboard shortcut next to it so I can remember it for next time.
In emacs, I have absolutely no idea how to discover features, and if I find something I still have to understand what the M- and C- mean
> In emacs, I have absolutely no idea how to discover features
The built-in "help" functionality[1] is really great. C-h a will find useful documentation for what you need 90% of the time, and the manual is there for most of the rest. It's particularly useful for keybindings - C-h w for "what's the keyboard shortcut for this command" and C-h k for "what command does this keyboard shortcut run.
I don't think emacs is "user-hostile" on purpose. You have to keep in mind, it's nearly 45 years old. This is almost unprecedented in computing.
Today's users expect different things than users did in the 70s (who expected different things than users in the 80s, 90s, so on). Emacs has been relatively consistent through time, which has been a huge boon to emacs users. The tradeoff is against current user's intuitions -- for better or worse, emacs does not work like other popular software today.
Calling this "user-hostile" comes off somewhat entitled. Emacs developers in the 70s/80s/90s/00s simply didn't know enough about today's users to cater to us, even if they wanted to. That's hardly their fault.
So, todays way and the emacs way have diverged some, and it does take a bit of effort to learn. Not because emacs hates you! But because emacs is ancient. The (objective, non-stockholm-syndrome) reward for your efforts to understand it are a) mastery of a system useful enough to survive this long, and b) mastery of a system that isn't likely to change out from under you.
> You have to keep in mind, it's nearly 45 years old. This is almost unprecedented in computing.
We can acknowledge Emacs's longevity without straying into unsupportable hyperbole. Emacs is nowhere close to unprecedented in its age and not remotely close to the oldest piece of software still in existence.
GNU Emacs is from 1984. It is a reimplementation of the earlier 1972 Emacs. This matters, since if you're including reimplementations then obviously Unix itself, which is used by many of us every day, it older. And if you start counting from 1984...that's not especially old.
I pointed out emacs' age to note how users expectations of editors have evolved over that time. Certainly there is older software -- but is there any other user-facing software that has survived such a dramatically shifting landscape? That is the part I find unprecedented (and the part relevant to GP).
Just because something is old doesn't make it not user hostile. If anything it encourages it as we are always getting better at making better interfaces.
Cars from the 70's don't have airbags. So, by comparison to what is available today, they are user hostile.
Hm. I take your point, but I'm not sure the analogy works.
Maybe better: "Old" (pick a date) cars had a manual transmission. Compared to automatic transmissions, you might consider that user hostile. But back then no one knew what they were missing and got along just fine.
Nowadays, some people still like manual transmissions! Not everyone, but some folks still buy them. Some even claim they're better than automatics! "They're cheaper, easier to maintain!" Are they user-hostile? I guess it depends on who the user is.
(Airbags seem like a strict improvement, sure. But part of that comes from them not being part of the "interface" of the car -- we don't interact with them, we don't form preferences about them, gain familiarity with them, etc. Perhaps they correspond better to multi-cored CPUs, multithreading, or high-res color displays (features emacs has kept with the times on, more or less). It's much harder to come up with similar strict improvements in the UI world.)
I seem to recall reading that the keyboards that emacs was originally developed for had the CTRL key in the middle left (where the modern, useless, "caps lock" key is). The awkwardness of the CTRL key on modern keyboards makes emacs seem unnecessarily user-hostile as well, but that's also not something that Stallman could reasonably have predicted.
My keyboard doesn't have a 'ctrl' key, it has 'control'. I don't know why removing all the vowels from the word is considered more 'correct' than referring to the key by the first letter. Both 'C-' and 'Ctrl+' are ways of shortening the word.
It also takes what, five minutes to get accustomed to? Even old dogs can learn this new trick.
When it was written, there were no widespread GUIs. Standardized keyboard layouts on computers were just starting to be a thing. Many of its users were using terminals, not workstations or PCs. So they adopted, and probably more often invented, terminology and conventions for a world that predated almost everything people today know and understand.
So it's not user-hostile, it's just really old. The knee-jerk answer would be 'well just update the conventions/terminology'. The problem is, update it to what? There is no timeless terminology they can use. As the tech industry increasingly resembles the fashion industry, they'd need to slap a new coat of UI paint on it at least every 10 years to keep up... as what was 'user friendly' terminology today won't be in not too many years. So now the developers are spending a big chunk of their time 'modernizing' it rather than actually making it better... not something most developers are interested in doing for a passion project.
Perhaps an example will be more vivid. In the eighties most people who were on the internet worked on a 24 line by 80 column terminal. Some people used Emacs buffers as a predecessor to multiple windows on large screens:
- Edit your code, perhaps splitting the screen in two buffers to look at different files or places in a large file.
- Split yet again one buffer for compilation error messages.
- Split the other one for a shell subprocess to run the program, check mail, etc.
Basically all-Emacs all day. Not my setup, but I saw it done often enough.
Expecting people to adapt to 1984 - which, just a reminder folks, is more than 30 years ago - rather than updating your documentation and maybe some keybindings to better reflect today is in fact incredibly fucking user hostile.
Ah yeah, the minutes of saved effort after pouring hours of effort into trying to understand esoteric arcane emacs-only concepts and writing some Elisp.
seriously though, it's a rabbit hole. Been there myself, now I just us vscode and it's a breeze!
The kindest thing we could do for future programmers is let Emacs and all tty-oriented editors die. There are much better options now. UI has improved a lot since the 1970s, let's embrace it.
Even by the standards of terminal-based applications, Emacs is far from intuitive or attractive - the text-based IDE's from Microsoft ("Quick" series) and Borland ("Turbo" series) were significantly easier to use.
(As another example where *nix systems could improve a lot, the Midnight Commander tty app is great, but still not quite as intuitive as the old 'DOS Shell'. Weirdly enough, I find that other TUI apps, such as dselect and aptitude, are quite outstanding but you do need to be on a Debian-based system - they aren't a thing on Fedora or CentOS.)
The issue isn't "intuitive or attractive". It's something more like "powerful, learnable, extensible". Nothing else scores as highly on that triad of qualities as Emacs.
I might agree, but the root post in the thread as linked by OP is literally someone complaining that Emacs doesn't have rounded buttons. (And no it was not posted on April 1, even though that's a sensible question to ask.) And there are other less trivial UX concerns about Emacs that are somewhat more legitimate, even for a tty app.
> Even by the standards of terminal-based applications, Emacs is far from intuitive or attractive - the text-based IDE's from Microsoft ("Quick" series) and Borland ("Turbo" series) were significantly easier to use.
They may be easier to learn (since they have pretty minimal functionality compared to Emacs) or easier to discover when you are new to them but they are definitely not easier to use. I use Emacs not because I am some kind of masochist but because it is the easiest way to get my stuff done.
Genuine question: what's different about SLIME/CIDER than any IDE? Auto-completion, documentation lookup, REPL, code reloading, unit test integration... these are all in Xcode, IntelliJ, Eclipse, Visual Studio, etc depending on language support.
CIDER can just as easily be built as a plugin to VS Code. (Actually, more easily.) It's just that the people who built it chose Emacs, simply because they personally prefer Emacs.
GUI Emacs is a very thin GUI skin on TTY Emacs. As an example someone brought up elsewhere in this thread, you can't scroll (with the mouse) in Emacs without bringing the cursor with you. Scrolling without moving the cursor doesn't make sense in a TUI environment, so it doesn't exist in the GUI version either.
Your second point is very subjective and most people are bound to disagree with it. You certainly can't argue that like it's an objective fact, because it's very much not objective.
> Scrolling without moving the cursor doesn't make sense in a TUI environment
It makes perfect sense as soon as you realize there is no reason the cursor has to be the cursor. In curses: curs_set(0); then draw your own 'cursor' wherever you like.
Anyway, GUI emacs is way better than terminal emacs. Image support (in terminal emulators this is always an awful hack) and support for different font sizes in the same frame at once is something I'd not give up.
That's far from obvious. I recall terminal interfaces rather fondly. Modern interfaces are often more like a flock of multi-colored rabid weasels trying to get in the way of my work.
I gave it an honest try for 6 months and even as good as Org-mode is (I used it to track project tasks, notes, timelogs, even had a go at custom templates), the 80s design choices and trying to find information that didn't expect a full working knowledge pushed me away from Emacs, might have been made worse trying to do this on "the devil's OS".
I'd have loved to have been able to give magit a go.
I agree! You know what takes it to the next level? Sticky keys!
Accessibility feature in macos where modal / control keys will "stick" for the next keypress (non-modal / control) and then release.
Double tap will stick it for the duration until the next tap on the same key.
Essentialy, double tap control key and move around with n and p keys, kill with k, move more, yank somewhere else with y. All without touching control! But there's more, you can save the buffer with x followed by s press. It takes a while to get used to but saves you awkward wrist moves. I guess it's closer to modal editing in vi, just not as advanced.
Or all movement combined with prefixes. I regularly do
C-u C-u C-p
to jump sixteen lines backwards. Or add another prefix and it's 64 lines.
Separately, macros, yea! Macros with regexes FTW! The counter you can use in macros - occasionally very useful! M-x occur! Dired which can search a whole directory tree of file contents for a regexp! So much more.
Only thing worse than emacs interface is not having emacs at all.
While it's nice that macOS has this out-of-the-box, you can make all the key-bindings to their macOS equivelants using Karabiner-Elements. If it did go away, we'd be fine.
So true. It's a major thing that stops me from migrating to Linux.
Every time I work with Linux or Windows, when I open a Chrome tab and I want to go down to a history completion, I hit C-n multiple times and it ends up with many new windows...
If they could make some kind of a visual layer that makes it look like Word and Photoshop (not in the same time, I'm being realistic here), their name would be remembered in eternity.
Of course, emulating the shortcuts & functionality of Word and Photoshop shouldn't be considered a problem, we are talking Emacs here after all...
A closer example might be autocad (at least older versions). You could do everything with a mouse, but a true expert could type the plans for a building faster than you can imagine.
Oh, if Emacs ever implement that visual layer, I don't think it’s unrealistic to expect it to looks like Photoshop _and_ Word at the same time.
Emacs already have a concept of frame, and you can already configure each frame independently (e.g. for term and X), all connecting to a single Emacs process, and can share buffers/yank ring/etc. across multiple frames.
There is a human aspect to software, and when you forget that, and try to force people to adapt to software instead of adapting software to people, you come up with software that naturally is difficult and unpleasant for people to use.
Emacs is built on a philosophy of human nature that deemphasizes the subjective personal experience in favor of (a limited group of people’s theory of) the objective ideal experience.
In a short amount of time, VSCode and it’s ecosystem has almost equally matched what Emacs and its ecosystem took 30+ years to create.
I think you're making the point that a majority of VS Code was funded by Microsoft, and therefore it can't be compared to Emacs which was either mostly or entirely coded by volunteers?
The vast majority of Emacs's usefulness is its ecosystem. Several Emacs clones have been made in a very small amount of time, but none have caught on because they lack the ecosystem and community. So it's only really fair to compare VS Code's ecosystem with Emacs's ecosystem. And VS Code's ecosystem was created by unpaid volunteers too.
It has taken much more than 30+ years to create, mostly by people on their free time. Isn't it amazing? I think it says a lot about perseverance and good engineering. How many editors have you already seen to rise and fall?
Emacs tries very hard to be helpful. It's software by the people, for the people. It's the very core ideal of free software. But yes, it doesn't resonate with most people because it takes time to learn.
Popularity is more of a marketing problem than an editor problem.
At the same time, if we compare emacs to vscode, vscode simply requires less configuration to get going. Given how much tooling exists in the javascript ecosystem, I think having a few plugins "just work" goes a long way.
Asking users to configure emacs from scratch to have a reasonable editing experience in their programming language of their choice is a lot. I think configurations like doom or spacemacs do a lot for this problem, but it really comes down to marketing.
I use it because it's installed by default on Linux desktops. That's not important to me now—I'm currently using Neovim compiled from source—but it was important when I was first learning to code.
I could probably switch to Emacs using Evil, but I don't see a compelling reason to.
Where I work nearly everyone uses Vim. We work in less popular languages that new kids on the block (VSC, Atom) don't really support. It really either Vim or Emacs. I think most people choose Vim because it is the default "Terminal based Editor" in most peoples minds.
i tried using both emacs and vim at the beginning. the problem with emacs, for me, is that the keybinds were basically to harsh on my wrists while vim was quite good, because i could keep my hands on the home row.
At work, I moved from Emacs to VS Code about a year ago. I’d used Emacs for years but I was spending a large amount of time fixing package upgrade problems. I guess I’d got into some kind of dependency hell. Maybe I wasn’t experienced enough with Emacs to use it professionally. But that’s the kicker, I haven’t had that problem switching to VS Code.
Having all of Elisp and all of Emacs available, including packages, is powerful. But it comes with a complexity cost if your config/dependency graph grows to large. Like any in-house software project really - of which a small business cannot afford to invest in.
There is one area, though, I’d use it again for: Lisp. Clojure with CIDER, CL with SLIME. As far as IDEs go, the level of language support for Lisp is phenomenal and without equal (but not surprising given Elisp).
What did you do about key bindings? The default vscode ones rely heavily on arrow keys, but those things are just so far away from the home key. I can't seem to find a move up/down paragraph shortcut to map either. I've tried some of the emacs plugins but they all introduce weird behavior; I keep ending up in some random menu vs just moving my cursor around.
In effect, gritted my teeth and got used to it. I mean, the basic movement commands still work (or you can configure it so) so that helps.
But the benefits out weigh the sluggishness I feel at the keyboard. It was easier to get the rest of the team on VS Code and then I could start looking at extensions that bring things as close to what’s in Emacs as possible. That’s improved team productivity as whole (and my own when they do the same).
But there are somethings I long for. Magit was hands down the best thing for projects versioned in Git. I’ve not seen anything like it in VS Code. The other thing is macros and Elisp but as above that’s a double edged sword. I’ve actually thought about bringing some of those ideas over to VS Code at least for my own team.
Does it need to be popular or need more users to become maintainers?
I use emacs because I can't imagine using anything else that has half the features and is harder to extend. I can't imagine why it needs to be popular. It's a programming environment that happens to have a text editor built in. That appeals to some folks but I can't imagine why someone interested in writing for publication would choose it over Scrivener or a word processor and why it's desirable to attract such users.
If I had a horse in the race I'd focus on the developer experience. Make it easier to extend, make the runtime faster (the native compilation stuff is super cool), better unicode support, alternate input methods, etc. If people want to use it for publishing it should be easy to write a package to cater to those users.
For me, a long time emacs user, I think the biggest concern I have is ensuring that the project is sustained by new developers.
I'm mostly satisfied as a user. I'm working on a mode for editing emojicode[0] and it's a weird edge case but it'd be nice if emacs worked out of the box with nice defaults for this sort of thing. More experienced library authors might have more to say about it.
Popularity means more users and more contributors. I guess most of the core emacs devs are greybeards who started programming in the 80s or earlier, so what happens when they grow too old? Who will replace them?
> I guess most of the core emacs devs are greybeards who started programming in the 80s or earlier, so what happens when they grow too old? Who will replace them?
What makes you say that? I don't think this is true. Not among the package maintainers anyways, and also of note here is remacs - I can't imagine greybeards programming in rust.
And popularity does not always mean more contributors, not when they are just the consumers of the product. The drop off in delta contributors / delta consumers is fast.
> What makes you say that? I don't think this is true. Not among the package maintainers anyways
I was talking about the "core developers" who work on the emacs core, not packages. AFAIK most of them has a long history with emacs, using it for decades, so they can't be that young.
But of course I know mostly about the maintaners and stuff. It's possible there are lots of younger contributors.
>What makes you say that? I don't think this is true.
the same thing that probably made you say this :
>I can't imagine greybeards programming in rust.
emacs is an older software package, from the 'original home of hackers', extended in a (sorta) language that is notoriously connected to old-school AI and academic programming. The holy war of vi vs. emacs has raged for decades -- and emacs/vi/lisp jokes are some of the oldest computer geek jokes in existence.
I can imagine the fans skew older then say fans of something like Electron or Flutter.
The only computer-geek-joke-theme that I can think of that'd be older would be the billions of COBOL jokes -- but that's just because i'm too young to have heard the billions of punch-card and wire-routing jokes that inevitably existed before I was here.
At the time Emacs was created, Lisp was one of the few languages that had automatic memory management and higher-order functions and error handling, but those have been lifted so often that they're now table stakes for modern languages.
I'm pushing 50 and excited about Rust because it's finally conceivable to have software that works reliably. I like Emacs, but it's not like I haven't seen my share of crashes in its kinda clunky C runtime. Hell, Rust even has macros.
The industry has been trying to write C and then C++ for decades, but it all blows up randomly. Buffer overruns, use after free, shared mutable state. Apparently tooling exists that tries to make Rust-like guarantees, but it's so costly I've literally never seen it used.
Much as Elisp is written in C, the JVM and CLR are each written in C++ and assembly, hosted on an OS written in C and assembly, and I've seen all of these crash.
I don't know much about QNX, but I haven't heard anything about seL4-type rigor going into it, so I wouldn't bet on it working a lot better than Linux or Windows.
Developer experience is more than just technical too. I know some package authors (and myself personally) find themselves very disillusioned with the GNU approach to contribution, especially regarding licensing and copyright assignment.
a lot of contributors/developers are bothered by the fact that they have to play ball with copyright laws, at all.
it's a fact of life for developers with projects anywhere near the GNU-scape that if you don't GNU it, you'll catch a lot of hatred, even worse if you choose to avoid licensing all together -- and gods help you if you choose a tongue-in-cheek licensing agreement like WTFPL.
at the end of the day a lot of people just want to contribute meaningfully to a project that they use and enjoy, but the headache of licensing and catching flak by choosing the wrong one (and since all the communities have opposing thoughts, they're all the wrong one to certain folks), it just becomes easy to 'forget to contribute' -- especially when your patch or whatever is working fine locally and there is little practical incentive to catch that much heat.
I think the legalese issues turns a lot of would-be contributors into local-patcher type developers, and then they leave for greener pastures once what they needed patched is on their own machine -- especially for projects like emacs where 90 percent of development is going to be towards extensions.
...and I say all this from a position of love and admiration for GNU and the FSF.
Yeah I completely agree. It's like, I agree with GNU and the FSF, but that doesn't mean I'm as strict as they are. I want to contribute to MIT, Apache, and BSD licensed projects as well, or I want to just not think about it and work on some project that has no licensing info whatsoever.
But (some definitely not all) folks are pretty all or nothing. There's a lot of jerk developers on the net though, maybe it's better to just ignore them?
I can relate. Used to be a hardcore GNU fan, but these days I'm probably closer to sqlite thinking (public domain, but work hard to avoid contamination).
As for contributions, presumably GNU wants ownership, but do they have a problem with assigning back what amounts to public domain rights to the author?
And I suppose, for most contributions, does it really matter? The awful truth is that I can't think of anything I've ever written that had freestanding value, as opposed to value as an enhancement to something else.
> A hammer does not have [an agenda], and that does not make it a less useful tool.
Sure, but by default all software has a copyright agenda built in. We can remove copyright, but there are two approaches:
- Remove copyright so that anyone can use your code, but then they can re-add copyright to your code and sue other people for violating their copyright.
- Remove copyright so that anyone can use your code and ensure that nobody can re-add copyright to your code.
I used to be in the former camp, but I've slowly moved to the latter.
It's kinda why I like the Mozilla license (MPL). Anyone can freely use (leech even) on the project, but if they make improvements or changes to the project they have to share. It also doesn't try to control how the consumer of the project is allowed to deploy such software either.
A cheeky license, or, worse, no license at all is a potential hole for a lawsuit. That is, of time and money wasted, and of the project being at risk.
I see why you might go with Apache, or MIT, or even straight public domain licenses. But as a maintainer, I would not accept a contribution which is not properly licensed, or which is licensed in a way not compatible with the project's license. Usually such a contribution is less valuable than the rest of the project, so there's no point to introduce a real legal risk of project's closure for the sake of such a contribution.
There's a world of difference between releasing contributions under the same copyright (i.e. if you're contributing to a GPL'd project, release your code under the same GPL license) and assigning copyright to the FSF. I think that's the turn-off for many. It isn't a matter of 'what would you even do with' the contribution, it's a matter of recognition and making it much harder to change the licensing terms down the road.
For those who just want to bury their head in the sand and pretend copyright doesn't exist, they will be the first to complain when the code that they wrote is taken private and commercialized (i.e. look at the licenses this has been an issue for)... making code 'public domain' allows for that.
What happens when the woke takeover of the SFS is finally complete and emacs is re-licensed under a new social justice license where you can only use it if you don't oppress minorities?
I don't trust the FSF further than I can throw them and I don't trust them with my copyrights.
Agreed... that was my point. Specifically, it doesn't matter who takes over or what the changes are, only that direction/priorities may change and be inconsistent with the intent of the original contributor.
The existing code cannot just be "re-licensed". It's true that they might decide to make future versions available only under some weird license, but that wouldn't cause prior contributions to become unavailable. Continuing the code line under the original license would always be possible, given effort.
I submitted a miniscule patch to tcl-mode (or font-lock) a couple decades ago. It was to speed up syntax highlighting for a particular style of commenting. Maybe a 3-6 line patch, tops.
I spent 20x more time back and forth on copyright assignments, including getting a release from my company, etc to get the patch in. I pushed through because I felt like I was always "just one more yak shave away from finishing", but if I knew at the start how much time it was going to take, I'd have kept the patch on our own private site-lisp. That's a problem, IMO.
The copyright release process where I work is pretty liberal, but the amount of people I have to get involved is fairly prohibitive. If your boss doesn't like doing paperwork, you're not going to get a release...
My memory is that my correspondence was directly with rms on this patch and it was required at the time, but the fact that it would no longer required is definitely beneficial, so thanks for that update!
> very disillusioned with the GNU approach to contribution, especially regarding licensing and copyright assignment.
TBF, given the historical FUD baggage, I don't fault them for trying to play extra safe as stewards of the project. Also, Emacs makes it so easy to get packages out-of-band (eg: MELPA, Borg, Straight, Quelpa) that I don't think the copyright assignment is a big deal unless one wants to get code merged into base Emacs.
Or, emacs in the browser. Popular editors like VS Code use monaco and now github has codespaces [1] which is running in the browser.
People live as much or more in the browser as the terminal these days, so bring the emacs sauce to where the people live. Maybe you could get some of the c compiled to web assembly, and the lisp would follow? It'd be neat to open a buffer to the page emacs lives in and start editing, call JS code, or embed emacs into a page as easily as monaco. Maybe the GUI components could be made out of HTML 5?
Would you realistically be able to bind enough emacs keybinds in a web page so that it feels natural? Or would you need some extra extension to help with that?
I'm not very familiar with how easy it is to capture browser keybinds in a web page.
You pretty much need an extension that runs in a separate window. You can already use Emacs through the Secure Shell[1] Chrome extension, but if you run it in a tab the browser eats too many key combinations for it to be useful. If you launch it in a separate window, then very few key combinations get intercepted and it works quite well.
So something similar to what Neovim is doing where it can be a headless backend for any editor that implements their protocol? Like eventually if JetBrains bothers, you wont need a VIM emulator for IntelliJ and co, you can just run Neovim and have it work with IntelliJ directly, without losing any of IntelliJ's benefits. Note: I also mean PyCharm, GoLand, and so on...
Neovim literally has like over 30 projects for new UIs:
> That appeals to some folks but I can't imagine why someone interested in writing for publication would choose it over Scrivener or a word processor and why it's desirable to attract such users.
Color me surprised! I'm turning into a stereotypical Linux greybeard but I must be true to my nature, and endorse Linux for writers.
There's this famous story, about the secretaries who mastered Emacs and preferred it to the other 'easier' administrative programs they were offered.
"Shel wrote Mailman in Lisp. Emacs-Lisp… Mailman was the Customer Service customer-email processing application for … four, five years? A long time, anyway. It was written in Emacs. Everyone loved it."
"People still love it. To this very day, I still have to listen to long stories from our non-technical folks about how much they miss Mailman. I'm not shitting you. Last Christmas I was at an Amazon party, some party I have no idea how I got invited to, filled with business people, all of them much prettier and more charming than me and the folks I work with here in the Furnace, the Boiler Room of Amazon. Four young women found out I was in Customer Service, cornered me, and talked for fifteen minutes about how much they missed Mailman and Emacs, and how Arizona (the JSP replacement we'd spent years developing) still just wasn't doing it for them."
Hell, there's even a 1-hour series on YouTube called "Emacs for Writers."
Spoiler: I skimmed it and it's as I thought - it's largely about Emacs and org-mode. Honestly, I can't argue with the classics. Here's my pitch.
Writers of the world: You are information workers. That means you have problems with the organization of information, probably, and - related - information overload.
Let Emacs help you with this!
It has a mode, org-mode, which is usually overcomplicated, but is basically as simple as markdown (no, really). Has anyone ever walked away from Markdown because it was too difficult to understand? Probably not. It doesn't have to be any harder with org-mode. In fact, in the next two lines, I'll teach you about 95% of how I use it - everything, in two lines.
* an asterisk before a line makes it like a sublayer of the layer/line above it; if you're on a sublayer, add another asterisk to make a sublayer of a sublayer, and so on ad infinitum...
* press tab to expand a layer or a sublayer you are on; press tab again to contract or hide it
That's it! That's 95% of the value of org-mode right there. It's the simplest way to organize information, in my experience.
Now, there are other advantages too, like: Emacs works with plain text, and plain text is super portable (everything can read plain text), fast to load, and can even be a convenient method of organizing things, if you give your files descriptive names and learn to use 'ls' to list things. Because those files are plain text, they take up almost no space, so it's fine if your computer has a zillion of them, it'll be blazing fast.
I could go on, but these two things alone make Emacs worth your time, and there's plenty of other advantages, like using LaTeX to make PDF's, you can 'grow into' also.
I think you've misunderstood why someone would prefer Scrivener or a word processor: a rich-text ecosystem that "just works", in terms of WYSIWG / rich text editing; being the de facto standard for many non-technical user; and being more than "as simple as Markdown", but actively providing a tight ecosystem focused on writing.
Is it possible to recreate some of this functionality in emacs? Definitely. But, it requires a lot of patience, exploration, and determination.
Your editor wants to add track changes and inline comments to your manuscript draft. How do they do that in your org-mode file?
You've received a .docx draft from a friend, or copy for your book blurb, or a press release for your upcoming publication. How do you edit that .docx and return it in better shape than you found it?
You're writing a novel, and it has extensive research notes, background material, and miscellany you're keeping track of. How do you quickly navigate between these multiple sources of content, marking things up, merging different aspects of documents?
I'm a die-hard emacser, and I do a lot of personal and academic writing in LaTeX. But honestly, have you ever had to reformat a LaTeX manuscript for journal publication? It can take hours just to get the damn file to compile.
emacs is worth the time, if you're inclined to tinker and invest the effort to get it to work—but for me, at least, that's a hobby. It's disingenuous to present it as a real competitor to industry-standard workhorse word processors. And most writers with a day job can barely find time to write, "investing time in emacs" is a nonstarter for getting things done! In fact, I tune my own org-basaed PIM system as a way to avoid getting real work done...
To be clear, by "your editor", I don't mean emacs—I mean the person who works at a publisher: she knows that a gnu is just a wildebeest and inheritance bequeathal of wealth; assumes "C-c ;" is just an obscure emoji; and will not waste her time indulging a writer who uses an obscure [1], roundabout way of entering text into M$ Word.
Look, again, you're preaching to the choir—I use emacs every day. But writing a Python script to generate my org-native ToC to navigate reference materials is just...a very different, more work-intensive beast than an interactive drag-and-drop IDE tailored to the needs of professional writers. Impossible to approximate, with enough determination? No. Possible to start using intuitively within the first 15 minutes? Also: no.
"Open my doc in notepad or any other text editor. Put comments wherever you want; if you'd be so kind as to put them on their own line with a # at the start it would save me some time."
Easy peasy.
The beauty of org is that it's just a text file. You don't need Emacs to edit it.
Is it really too hard to imagine why the creator of the Free Software Foundation would rather people use a free software text editor over the current proprietary alternatives?
I find word processors with all their formatting, hyphenation etc. capabilities more of a distraction than help. IMHO they are better for publishing a text than for writing it. Even a simple text editor seems like a better choice.
I dunno... I think newer editors are often easier to extend than emacs. Think atom or vscode or even sublime.
They're all extensible enough such that emacs has no real major advantage IMHO. They can be extended with mainstream languages that many programmers already know, instead of an idiosyncratic lisp with no practical application outside of emacs itself.
Emacs still has some great modes (like tramp) - but overall, I don't think its customization is really a special killer emacs feature anymore.
I've had to write simple plugins for both SublimeText and VSCode to get the equivalent of a one-liner in Emacs. Comparing anything with Emacs extensibility is not even fair. There are hooks for everything, you can invoke other people packages from your own code, if you want trouble you can overwrite other people's packages specific functions, etc.
Emacs has a lot of flaws though. I don't really recommend people using it. Even after showing the neat stuff, I can do with it.
> I dunno... I think newer editors are often easier to extend than emacs. Think atom or vscode or even sublime.
Can't see how. It's hard to be easier to extend than being able to just wrtie a line of code in an init file, do M-x eval-region on it, and be done. You can extend Emacs 100% through ad-hoc manner, and none of that requires any extra infrastructure. I don't think VSCode or Atom are approaching anywhere close this level of flexibility.
I’ve been porting the Sly IDE to Sublime and basically I would say Sublime is a hostile development environment, a lot of times errors dont trigger stack traces and just silently fail which is super frustrating.
Why would you want to become a maintainer when your suggestions will be blocked by a guy who doesn't even know what org-mode is, hasn't coded in decades, and insists the terminology has to pretend it's 1968?
> Does it need to be popular or need more users to become maintainers?
Yes.
> I use emacs because I can't imagine using anything else that has half the features and is harder to extend.
Maybe imagine harder or (just an idea) stop imagining and see the real world?
> It's a programming environment that happens to have a text editor built in.
Read the history of emacs again. It originated as a set of macros over TECO to make editing easier (hence the name emacs). Editing is always the primary function, the lisp interpreter was an afterthought.
> That appeals to some folks but I can't imagine why someone interested in writing for publication would choose it over Scrivener or a word processor and why it's desirable to attract such users.
Read the linked thread again. One "such user" is RMS. That pretty much has been his goal since the 90s to make Emacs a better word processor.
I think a large part of the issue is the default keybindings (the GUI is also bad, but I think it's bad in a way that's not going to be impossible to fix without screaming from people who like what's already there). It's truly only lacking a decent text editor.
This isn't to say that the keybindings never made sense; in the stage of computing before X, where Space Cadet-like keyboards were common, it was more than fine.
Currently, though? Entirely different era of computing.
Imagine you're walking in with no clue. You haven't heard of any of the memes, someone just recommended you a text editor. "It's really good! You'll be more productive!" You have no idea what in the world evil is, or why you would ever want it.
You launch the tutorial/tour/whatever it's called and immediately it yells at you to use C-v to jump to the next page. And then M-v to go backwards! If you're a normal user, your response is probably something along the lines of, "Like, why?"
Off to a good start, breaking the most universal keybinding across modern operating systems in the strangest way possible, and not only that, but also breaking one of the biggest implicit rules of keybindings.
You read a little bit more and eventually get to cursor control. Wow, somehow they managed to pick the only possible thing less intuitive than 'hjkl'! Not only that, but it's not even consistently unintuitive!
And that's not even getting into the obvious problems that come with the placement of M and C on modern keyboards.
There are a few solutions to this, obviously, but good luck trying to find a solution that isn't universally-hated.
You could make evil the default. Controversial and only slightly helps the barrier to entry.
You could make it like the Web's model of text-editing but with quality-of-life enhancements. I think this one is probably the winner. It's definitely why Sublime/VSC/Atom won, past everything else.
The Turbo C/Wordstar approach was cool, but has no mind-share today.
You could try something new, I guess? This is dangerous territory, though.
I have no idea what the solution is, but the problem(s) seem obvious. I say this all as a person who really likes Emacs. I even still have most commands memorized despite not having touched it for years now!
> You launch the tutorial/tour/whatever it's called and immediately it yells at you to use C-v to jump to the next page. And then M-v to go backwards! If you're a normal user, your response is probably something along the lines of, "Like, why?"
The hardcore emacs users think these keys are better. And don't want to change them, because then they had to rewrite the whole manual which uses these keys.
The user don't have to use these keys, though, so there is no point in the tutorial starting with them.
Right? And yet I just typed 'emacs tutorial' into DDG, and the first three results all hit you right away with descriptions of keys that don't physically exist on a modern keyboard.
I've never tried emacs in large part because I've been convinced over the years that the various combinations of keys I would need to memorize are too complicated. I just did that search thinking that maybe I'd been mis-remembering, but no, that's still the impression that I have.
I'm curious, how do you remember key combinations in other IDEs? I learned Vim, it was tough, but I remember a handful of commands I use all the time. And used Vim mode when available in IDEs when available. Spent a few years with VS Code, but I could never remember certain keys to navigate between panels for example. But the F1 key is great though. For w/e reason, I tried Emacs with evil-mode. I don't have to remember that many new keys I think, but a few of course. 'which-key' and M-x enables me to search for all commands, and I can also see the key combinations if I need to learn it later. In VS Code I try the F1 key, but if I could not find it there, I would grab the mouse and click around in menus looking for key combinations. Or go into settings and try to find w/e I was looking for. Of course, in Emacs I have spent hours setting things up, searching on the internet for clues on how to get something working as expected.
Perhaps I am doing something non-optimal in my process. Curious how others learn/get productive in their respective IDEs.
In most IDEs, they're the same key combos I use in non-IDE products. I'm on a Mac, so Cmd-X, Cmd-C, and Cmd-V work pretty much everywhere. They even work at a terminal prompt, and the latter two work in vi.
I did learn vi years ago, but I'm sure I still don't tap but 10% of its power, despite using it daily, precisely because the key combinations seem arcane to me.
I am having trouble finding that in your long comment. The initial experience of using vi and emacs are hardly different in some fundamental way so either being unintuitive seems like a poor way to explain their respective popularity (or lack thereof).
You read a little bit more and eventually get to cursor control. Wow, somehow they managed to pick the only possible thing less intuitive than 'hjkl'!
The initial experience of vi is that you learn six keys to press to make it do things, and go from there. Emacs is significantly more complex than that, starting out.
It's definitely not intuitive, but it's an order of magnitude of difference from Emacs, which could be described as anti-intuitive.
Vi has text input modality, unlike essentially, well, anything. It's an entirely different model of operation which it shares with no current software and hasn't for a quarter century.
It's strange to be talking about the UI details of vi/emacs (both, by current standards, about equally super-weird) when the article itself is a kind of perfect vignette of the organizational dysfunction of the group that maintains emacs.
'press i and then basically everything works as you'd expect' is pretty simple; it's got a significantly-smaller barrier to entry than Emacs, and breaks fewer core-assumptions. Is that agreeable to you?
The thread on the mailing list was basically guesses as to why Emacs has lost popularity & methods of regaining it, and the lwn article is primarily focused on just relaying it. The thread itself doesn't point to all that much dysfunction, in my opinion.
> 'press i and then basically everything works as you'd expect' is pretty simple
If that means that you can press letters in they keyboard and see them appear in the screen that’s also true in Emacs... and you don’t even have to press ‘i’ for things to start working as expected.
In vi if I press "i" I can't use the arrow keys to navigate the text as normal. In emacs I can. I'd say using the arrow keys for navigation in text fields is a very widely accepted functionality. So isn't it vi breaking the expected behavior here?
'press i and then basically everything works as you'd expect' is pretty simple; it's got a significantly-smaller barrier to entry than Emacs, and breaks fewer core-assumptions. Is that agreeable to you?
It's not. Maybe we're talking about completely different things because I'm not following this at all, just like the other responder downthread. For decades, GUI text entry has been modeless. Larry Tessler one of the GUI's pioneers and prophets (PBUH) had a 'NO MODES' license plate and the idea remains a central theme in UI design. Vi doesn't do that. It does this:
I don't mean to debate the merits of this design but in terms of 'breaking core assumptions, vi 'breaks the core assumption' of typing text into a computer. It's not, per Winnfield, the same ball park, same league or even the same sport.
I think that the Emacs concept is really good, but it clearly has a lot of problems that make it altogether unattractive to new potential users.
- The keybindings are not the standard CUA ones. Even with Cua Mode, every page on the internet still suggests using the regular old Emacs keybindings. There's weird conflicts between some packages, especially if you use non-default keybinds like Evil. The defaults are not even ergonomic (Emacs pinkie is a thing...) or mnemonic, so there's really nothing but historical interest that makes them the way they are.
- There's no namespacing between packages. They can run right over each other and cause weird bugs. This isn't theoretical; it's what happens when you have a bunch of packages installed. Sorting out performance issues caused by the interactions between packages is very challenging.
- Lots of other defaults are super user-hostile. To get anything approaching the productivity of an editor like Sublime or VS Code, you have to spend hours installing packages, learning their unique keybindings, and sorting out conflicts.
- The base is minimal in a way (it's missing a ton of what is needed to be considered useful today) and also very bloated (it has things like mail readers and web browsers and IRC clients included). The set of default utilities needs to better match what people actually use a text editor for.
At the same time, it does do plenty of things right:
- From anywhere in the editor, you can run code---you don't need to make a new package to be able to execute a snippet of Elisp.
- Unicode works OOTB, which is impressive for a project of that age.
- Some of the "killer apps" like Magit and Org-mode are really good and have spawned their own ecosystems.
- Emacs is oftentimes the first editor to get support for super-obscure programming languages through a package.
A lot of what makes Emacs so cool and so difficult comes from the fact that it doesn't have an "extension API"---packages just run the same kind of Elisp that the editor itself is (mostly) written in.
Edit: I should also add that Elisp is an absolutely terrible programming language when compared to more modern alternatives.
> To get anything approaching the productivity of an editor like Sublime or VS Code, you have to spend hours installing packages, learning their unique keybindings, and sorting out conflicts.
To an extent, yes, but I would say that the Vim philosophy involves utilizing external tools much more than in Emacs. Vim packages like the one for Go (https://github.com/fatih/vim-go) feel better-integrated into Vim than the equivalents do into Emacs. This is mostly subjective, so I can see where you're coming from.
> - There's no namespacing between packages. They can run right over each other and cause weird bugs. This isn't theoretical; it's what happens when you have a bunch of packages installed. Sorting out performance issues caused by the interactions between packages is very challenging.
without sacrificing your pro?:
> - From anywhere in the editor, you can run code---you don't need to make a new package to be able to execute a snippet of Elisp.
The fact that you can go to any package source file, modify a function and reload it on the currently running emacs instance (with C-M-x/eval-defun) kind of depends on definitions being standalone and at the top-level.
You can have namespacing in the form of prefixing identifiers with the package name. If there's name-clashing between packages, it's because they didn't follow that convention.
What more would you want out of namespacing that you can get without sacrificing or limiting that pro you mentioned?
> Edit: I should also add that Elisp is an absolutely terrible programming language when compared to more modern alternatives.
There are many reasons to hate pretty much anything. I'm not sure how you expect one to respond, if you don't give some idea of what it is that you find terrible about it. It's always pros and cons with most things.
"modern" also doesn't mean anything. Are you talking about languages that were invented recently or that are still maintained, evolving, and/or used despite being invented in "non-modern" times? Where does "modern" even start?
Agreed. I personally had never any problems with packages overwriting each other. Everybody knows that you have to namespace all the functions and it works, just like it works in C.
And the upside that everything is accessible in the scratch buffer is really worth it.
And for me, Elisp has been a kind of constant during my career. I wouldn't bet that in ten years, I'm still doing Typescript or Javascript. But if I'm still into programming computers via keyboards I will definitively use Emacs for that.
> I should also add that Elisp is an absolutely terrible programming language when compared to more modern alternatives.
This is a commonly seen complaint, and I do not completely disagree with you. But really, if there were better options to create an editor on top of some sort of lisp-machine equivalent, why are there such few equivalent editors out there?
I would be happy to move to a new mature ecosystem that allows the sort of flexibility offered by emacs, on which tools like magit and org-mode may become popular, but I am yet to find anything in the same ballpark.
> Edit: I should also add that Elisp is an absolutely terrible programming language when compared to more modern alternatives.
I think it's arguably the second-best language out there, losing out only to Common Lisp. Maybe third, after TCL. I certainly wouldn't want to use JavaScript, Go or Rust to extend my editor …
> There's no namespacing between packages. They can run right over each other and cause weird bugs. This isn't theoretical; it's what happens when you have a bunch of packages installed. Sorting out performance issues caused by the interactions between packages is very challenging.
The worst aspect of this is keybindings. As "free-form" as Emacs is, I think it would benefit greatly from having a centralized "database" of all (custom?) keybindings. I am sick of defining my own super-cool keybinding and then either having it get overridden by a package or unknowingly overriding a package's keybindings. I kind of wish a warning would be thrown or something if you try to bind a set of keys that's already bound.
I don't know what system would be good/better, but I know I hate it as it stands today.
For some reason I now have 2 versions installed on my pop-os, (I know to pick the first one when I launch from a gui..)
I love the editor, I really like the macros, and can move around and do my editing quick.
but I've been using it 10+ years and have NO idea if I'm using it correctly.
Certain modes aren't installed depending on and its just kinda obtuse. "Space emacs"? How do install a plug-in again..
where is my .emacs config file? is it init.el? ...
Honestly the hardest part about emacs for me has always been documentation. Like how do I build a plugin. What function do I call to set a custom key binding? This stuff has always been so hard to find despite it being so important to the underlying experience. Now that I've used it for a while I know these things, but they didn't come easily.
It's ridiculous that end users should rely on third parties for reliable documentation. For any other tool, if you wanted to know this kind of builtin functionality it'd be readily accessible in --help, the man page, or first-party online docs. Why should Emacs be an exception?
How on earth was RMS unfamiliar with the existence of Org Mode, and how on earth was RMS unfamiliar with the concept of outliners, and why on earth, when he finally figured out what Org Mode did, was his immediate response to be super dismissive because it wasn't something that he's interested in using personally?
He sounds like some random person spewing random subjective opinions about things, rather than the original author of GNU Emacs making an honest effort to provide leadership and guidance that means something (anything) to anyone other than himself. He sounds helpless and oblivious to everything and everyone except his own personal proclivities, which is the opposite of leadership and the opposite of an experienced person providing valuable guidance to the community. Like he's not even making a token effort to do those things, and to say he's metaphorically lifting a finger here to provide leadership and guidance would be very generous.
This is akin to Linus rejecting a driver because he doesn't own the hardware, or because he doesn't like the colors of logo of the company that makes it. It really doesn't get more incurious and intellectually/emotionally immature than that.
This is in 2020, after a couple decades of Emacs being one of the only actual software projects he involves himself in anymore. To be clear, I've had a really low opinion of RMS for going on 20 years now (after a few years in college where I thought he was cool because I didn't know any better and people seemed to revere him because they thought everyone else revered him). But reading these mailing list exchanges are still kind of shocking to me. It's really hard to believe that anyone on the GNU mailing lists pay any attention to him at all, or values his opinion on anything. For those that do, surely that's nothing more than a cult of personality, it just seems as plain as day to me. This is exactly the sort of thing that drives people away from GNU and the FSF, and it sucks because they could be so much more impactful and meaningful and helpful and positive and constructive otherwise.
Sometimes I think if more people had simply stopped making excuses for RMS like 20 years ago, we might currently be living in some sort of GNU utopia dreamworld where everyone everywhere uses Emacs for everything, and GCC is the preeminent compiler suite, etc. etc. etc. It's quite a high cost for people to pay, when the only thing they get in return for keeping this guy around is helping a damaged narcissist continue to feel good about himself and continue alienating everyone else, just like he's been doing for decades. He absolutely got GNU and the FSF off the ground and helped create a large community that has produced tons of great software, but in the past 25 years it seems like all of his efforts have been counterproductive to his own goals.
> How on earth was RMS unfamiliar with the existence of Org Mode, and how on earth was RMS unfamiliar with the concept of outliners, and why on earth, when he finally figured out what Org Mode did, was his immediate response to be super dismissive because it wasn't something that he's interested in using personally?
He seems out of touch even with modern emacs packages. He doesn't use any of them, doesn't even know what they do, I guess he uses the same config since the 90s, doesn't try new packages, he's more interested in preaching the GNU message.
> He seems out of touch even with modern emacs packages. He doesn't use any of them
And he believes the right thing for the core Emacs-developers to do is to spend their time trying get everyone in MELPA (a modern package repo, with a modern GUI, based on modern tools and workflows) to instead move their packages to ELPA, with all the change in tools, modernism’s and workflows that entails.
He seriously believes this is important because MELPA isn’t GNU, and that’s all he cares about. It’s not enough to be open-source and free. You must be GNU, or it doesn’t matter.
He may add things of value still, but I refuse to believe it’s not overshadowed by all the backwardisms he constantly tries to impose on the core developers actually doing the dirty work.
> which is the opposite of leadership and the opposite of an experienced person providing valuable guidance to the community.
Following the discussion on Emacs-devel it does seem quite the opposite: you often see people with progressive ideas moderating themselves to not get too out of line with RMS. People (unconsciously?) try beating around the bush, to avoid touching GNU dogma, rather than going straight to the point, communicating efficiently.
While I really appreciate what FSF and GNU has done for computing, I believe the limitations Emacs-developers are putting on themselves by religiously denying to integrate with anything non-GPL (another Stallmanism) is going to hurt Emacs long-term, rather than benefitting GPLed software.
A shame Stallman put the kibosh on QT quickly. Is he planning on there being a GPLv4? Not in the "leaving that option open for the future" kind of planning, but more, "A need has been identified that can't be met by v3, it's time to start working on v4." Because if they truly want a cross platform visual interface, AFAICT, QT is the closest you're going to get, and IMO, is the best means of doing so. Every QT app I've seen has looked and acted a lot closer to a native app on Windows and Mac than anything that ever came out of GTK or other GUI toolkits. And I don't understand why GTK doesn't have the same issues. It's not a GNU project AFAIK. It can't be a GPL vs LGPL thing, because QT is also available under LGPL. Is Stallman perhaps just stuck on the fact that QT was once not available under a free license?
Okay, but even if GTK is a GNU project or a FSF project, why does that mean it qualifies for being part of a future GPLv4 licensed EMACS, and QT does not? Both are available under the LGPL. I wonder if Stallman expects that a GPLv4 would likely or definitely be incompatible with LGPL3. I don't think it's because the LGPL version would be bumped if a v4 came out; GTK is still on LGPLv2.1
It is because of the license. GTK's license is LGPLv2.1 or later[0]. The important part is later, It means you can update it automatically to any later version, especially if the new license is not compatible with the previous version. Qt does not offer their software with a similar license.
Qt is licensed under GPLv2 or GPLv3, while GTK is LGPLv2.1+. If the FSF makes a GPLv4, GTK will automatically be available under that license, while Qt will not.
> If the FSF makes a GPLv4, GTK will automatically be available under that license, while Qt will not.
If that were the case, then why was GTK not updated to GPL or LGPLv3 when the FSF came up with that group of licenses?
When I looked it up, I found that QT is available under LGPLv3[1], so unless there is already plans to ensure that a GPLv4 is not license compatible with LGPLv3, I don't buy it.
> A need has been identified that can't be met by v3, it's time to start working on v4.
Software-as-a-service under GPLv3 isn't required to provide source code to remote users (AGPL acommplishes exactly nothing in this regard), so there definitely is such a need, but I don't know if RMS is actually working on that.
Well, the biggest problem is that the AGPL isn't the GPL, so the existence of the AGPL doesn't actually help with the large number of existing GPL projects, even if they're licenced as "GPL version N or later" (which v4 would help with).
However, the problem I was actually thinking of ("exactly nothing"), was that last time I looked into it, the consensus appeared to be that you could copy code between a AGPL project and a GPL one, which obviously makes the AGPL useless. But, on checking, I can't actually find a citation for this, and the licence text doesn't seem to support that interpretation.
So I have to retract my previous statement and amend it to: the AGPL does very little to help with SaaS attacks on open source software, primarily because almost noone uses it, and because the FSF continues to recommend the known-broken non-affero GPL as its default copyleft licence.
For me, I’ve recently started using Emacs solely due to wanting to try out rust-analyzer¹ (not touching Visual Studio Code since it uses Electron), and I’m really enjoying how insanely customizable Emacs is! The ecosystem around Emacs looks great too, with quite a few packages I´m interested in trying (like Magit²).
I cannot possibly encourage you more to check out magit. It is unbelievably good. I always share this demo with people to show off just a tiny portion of what it's capable of doing
My skills with git have gotten better after using magit, too, because it brings the power of git to the surface. It's a really fantastic git porcelain and the fact that it is deeply integrated into Emacs just makes it absolutely second to none.
Magit is easily one of my favorite pieces of software and I will leap at the chance to sing its praises.
The Emacs community has held itself back by continuing the line of thought of resisting anything that fundamentally changes what they already have spent years learning and know. It's their power tool, and using tools is important for humans to do their craft. So I understand why they don't want anything to change.
Meanwhile new generations of people have different tools and aren't held onto these past ones because they didn't start with it (and they weren't coding in the 80s). The world of computing generally has moved on with new ideas, new experiences, and new form factors. So their new tooling has won them over, and outcompeted a dying generation.
This is a good thing! It's called progress. Unless Emacs is willing to have fresh blood decide a new direction for it, it will be relegated to history. If Apple held onto its Apple II vision, we wouldn't have the iPhone today. Either you are willing to fundamentally change with the times, or you aren't. Emacs has shown they aren't, and they've had over three decades to do so. Fortunately others will in their place!
Newness contradicts creativity, because the creative process needs to result in objects that last. In fact, because new designs create a future need for more new designs, it cannot last by definition!
Think of shops that sell novelty items. Newness at an object level looks like novelty items. What is the quality of novelty items? How long do novelty items last?
I don't understand your point. We're not talking about physical things, we're talking about software. Software is always changing, morphing, adopting, and growing user bases. It's what's amazing about it compared to hardware. My 2012 MBP runs the latest OS from approximately 8 years later, and with it a whole new slew of features and additions that both Apple and the rest of the world have brought it. Why be stuck in the past?
There's truth to that - we do not feel the need to 'upgrade' Mozart's or Titian's works, they feel just as interesting as they did when they were created (if not even more; and I am not talking about a "purely historical interest").
We don’t know when vscode will or won’t go extinct. It’s less distinct than other similar editors in comparison to emacs, so the switching cost is a lot lower. But my point being isn’t that vscode will somehow be “the great winner,” but rather that new things will come and continue to replace the old.
Emacs has/had the option of changing with the times. They’ve opted out of that. So most newcomers will opt out of emacs, and thus it’ll slowly die out.
I wish Vim users and Emacs users would unite to improve Spacemacs. It's really a great idea IMO, have the editing power of Vim with the flexibility and elegance of the Emacs environment.
Unfortunately when I tried Spacemacs (coming from Emacs) I kept bumping on rough edges with vim command emulation which ended up with me switching directly to the real vim. It's been about a year now and while I still think I was right to finally make the switch to modal editing, vim feels like a clunky and hacky environment compared to the power of Emacs.
As someone who really doesn’t “get” or care for Vim, why should I contribute to an alternate Emacs-“distro” entirely focused on an existing Vi user-base, using non-standard conventions and keybindings?
I mean good for them having that option, but what’s in that thing for me?
This is one of the main reasons why I stuck with Vim. The strain on my hands was very noticeable, even as I was just starting to learn the standard Emacs keybindings..
Thanks for the evil-collection link! I hadn’t seen this before, but the sudden switch out of having vim bindings in various buffers has been one of the pain points in starting to learn emacs.
I don't think spacemacs and the vim emulation, evil, have anything to do with each other. I switched from vim to emacs a while back and haven't had any issues with evil mode.
As far as spacemacs goes it seems neat. I tried it once but it was too confusing and I've been using emacs for so long now that it's very finely tuned to what I need it to do.
Vim and Emacs have too many philosophical differences for this to work. For example, emacs doesn't have a fixed concept of what a paragraph should be. Instead, it leaves that up to the major mode. This is fundamentally incompatible with vim's paragraph motions which are determined by empty lines and remain the same regardless of file type.
As a very long-time Vim user, I prefer that my editing commands be predictable since I type them with muscle memory (faster than ordinary conscious thought). Having them vary from file to file based on file type (the Emacs way) throws me off completely and makes the editor feel untrustworthy, like a horse that's liable to kick or throw its rider. Vim feels like a complete set of high quality, manual woodworking tools.
Interesting viewpoint, but aren't there enough differences between programing languages to warrant mapping these concepts slightly?
Clearly my Emacs origins show here, because not having simple built-in motions to select "a function" or "a class" feels like a big limitation to me. I actually have a bunch of ad-hoc bindings for that. I also seldom use paragraph motion while coding simply because it doesn't really make a lot of sense to me. I think about code in lines or blocks, not paragraphs that is a rather weird concept when it comes to code. The fact that you can't easily add new motions to vim is a big limitation for me.
>Vim feels like a complete set of high quality, manual woodworking tools.
They're mostly reliable and predictable, I agree with that. High quality I'm not sure. The fact that the undo tree is effectively unusable without 3rd party plugin is weird. Tabs are at the same time over-engineered and under-featured. Nobody seems to really knows what they're for or how to use them (just make a quick search online for "vim tabs").
They're like Emacs frames except that you can't actually use them like a separate frame on a different screen. And you can't have them use a different working directories easily so they're useless to open two projects side-by-side. Some people coming from editors that open files in individual tab (an anti-pattern IMO, but that's a different discussion) expect them to work that way, but it turns out that they can't really do that either. Why even bother?
You also need plugins to do very basic coding stuff like run "make" in the background without being locked out of editing. Which wouldn't be too bad if Vim's internal API made it easy to make Vim plugins work seamlessly like native code, but in practice all the plugins have tested needed to be super intrusive to offer basic functionality (like remapping literally half the keyboard to slightly tweak the kill/yank behavior) and it ends up breaking left and right in weird and unexpected ways.
The visual feedback for commands is atrocious. Spacemacs' genius is that when you start typing commands it shows you what you can press next and what it does. You effectively navigate the bindings like menus, and you have this positive feedback loop where you memorize the bindings by using them. Sometimes I start typing a command in vim and I think I made a typo but I can't know because I have zero feedback on the current state of vim. Emacs almost always tells you what it's waiting for in the mode-line.
Why does ":bdelete" also kill the window it's in, except when there's only one window left? Since elsewhere there's no 1:1 relation between windows and buffers, you'd expect to get the next buffer in the stack (that's what Emacs does in this situation, and that's what Vim does when you have one window left). Window and buffer handling is hard but Emacs is vastly more configurable and works better out of the box in my experience.
I also often get performance issues that I don't remember ever getting in Emacs which is fairly ironic given that Vim is supposed to be the "lean" one.
I think so. The Emacs philosophy is essentially to treat the editor like a highly-customizable IDE. I use Vim only because I want a Vi that has a few quality-of-life tweaks here and there (the undo tree works fine for me without any plugins, I just use g- and g+). I don't use the vast majority of what was added. The core of what I want was created by Bill Joy back in the 70s.
I want a text editor that works the same whether I'm editing a C source code file or a text file that happens to have some C pasted into it or a configuration file or a file that looks superficially like C but happens to be a different language. I'm not interested in an IDE. I would prefer that most of those language-specific tools be separate programs that I can invoke by shelling out.
Performance issues in Vim are usually caused by various autocompletion engines, none of which I use. I like Vim's built-in completion which is very simple and predictable (fitting the theme), invoked using C-x in insert mode.
VIM has a text object called block that IIRC differs from filetype to filetype. I never tried but I guess you could also overwrite the ip and ap text objects for certain filetypes if you really wanted to.
As a vim user, I use Spacemacs for Lisp. Otherwise, I don't like mode inconsistencies (e.g. vim keys don't work inside SLIME debugger), the lack of tabs and the startup/running footprint. It doesn't feel right or convenient to have many Emacs instances scattered throughout tmux or terminal windows, created and killed as needed. Now that I'm thinking about it, this and tabs help me map my work space mentally in a way that hidden buffers (or directory trees) don't.
Although there have been several tab addons for emacs for a while emacs now has native tabs that work the same as vim tabs.
You can run emacs --daemon at login and run either emacsclient to start a new window connected to an existing instance. In my measurements starting vim in a new xterm takes about 250 ms. Starting a new gui emacslient requires only 500 ms. Perhaps numerously running a new default emacs instance with emacs -Q is actually faster at 400ms.
Emacs might never catch up to Visual Studio Code, which is actively funded by Microsoft, but intuitively, it seems like Emacs ought to be able to catch up to Vim. It's always been weird writing Emacs extensions in ELisp, but it's not like Vimscript is a top-tier language. Emacs is hard to learn, but so's Vim.
I think it comes down to performance, especially startup time. Emacs developers have never cared much about it, and I think that's connected to its reputation for "bloat."
The death knell rang when Linux distros stopped distributing Emacs by default; Emacs isn't installed by default on Ubuntu or Fedora, say nothing of macOS or the Windows Subsystem for Linux.
If I were working on Emacs, my #1 goal would be to beat Vim on startup time--to get the first page of text to show up faster than Vim--and my #2 goal would be to convince the major distros to include Emacs by default.
Sadly, I don't think any of this will happen. Stallman is too far out of touch, not just with newbies, but even with active users of Emacs. As the article points out, he's never even used Org mode! https://lwn.net/ml/emacs-devel/E1jR5ss-0001xM-L9@fencepost.g...
EDIT: I know you can do some non-default techniques to make Emacs start faster. But that won't get Emacs to be installed by default on popular distros. Installing more plugins won't make Emacs the quickest and easiest way to edit a file.
Startup time can actually be really good if you configure it right. Stock Emacs is about 150ms for me. There is also a portable dumper that will save your Emacs boot Image to memory for faster loading. Also check this out.
Sure, or you could use "emacs -Q," but all of those performance improvements are off by default, and it seems like they always will be. As long as that's true Vim will always be the quicker and easier way to modify a file.
Some distros have significant Emacs start-up configurations, which have an impact on start-up time. Using "-Q" skips this too. It's the case for Debian, so Ubuntu too I guess.
I used to use "jed" as a close to Emacs, light text editor to use for a quick edit from the shell. Nowadays I aliased jed to "emacs -nw -Q" (-nw: text mode, -Q: skip all configs), which subjectively starts instantaneously. And even a bare Emacs skipping the system an my configurations is very powerful. It also supports millions of colors with Konsole, so it's nice when reading code.
If you use the Emacs server/client, then it is very fast to open a file from the command line. But I prefer to just open files from within Emacs. With ido-find-file, I get fuzzy path matching, which makes it fast to find whatever.
Rather than worrying about startup times, I'd have them work on including a lean set of quality of life extensions by default, like ido.
2) You already use Emacs. What would it take to get a new user to use it? It would have to be installed by default, and be the quickest and easiest way to edit a file. That means startup performance.
Emacs itself starts fast. Most people who use emacs have a lot of packages that load on startup or autoload files that need to be read and this makes startup slow. Maybe if saving an image were easier then things would be faster but I think most serious users don’t care because they start emacs once a week
Out of the box, Emacs is slower than vim, and this is part of the reason why Emacs isn't installed by default on distros. Serious users don't care about startup performance, but that helps to explain why Emacs isn't gaining new users. Emacs isn't the quickest and easiest way to edit a file.
In the Emacs manual, read the "Saving Emacs Sessions" chapter (or get there from the 'desktop-save-mode' function documentation). Emacs can save and restore your current session, with opened files and windows layout, and as usual it's highly configurable.
By default it uses a global session context, but for example I configure mine to save the session locally in the directory where emacs is started. Then I can have several projects in parallel, and when I start emacs in the project top level directory it restores the session for this specific project. I also make the session saving file name machine specific, and ignored by unison for file synchronization. So the layout is specific for each machines with possible different screen setup leading to different window organizations. Just an example, you can tune it to fit your own needs --- that's the whole point of Emacs to me.
Not only does the desktop session remember and re-open the files, but it also remembers what frames you had open, what position on the screen and which screen the windows are on.
And no actual timings eh? My emacs starts up within 3 seconds. 2 seconds of that is it reopening all the files from my last session and arranging them on screen, saving me quite a few more seconds of doing it manually.
> my #1 goal would be to beat Vim on startup time
You have some weird priorities
> Stallman is too far out of touch ... but even with active users of Emacs
FUD! He monitors the emacs bugs list. Also I just 2 days ago got a response from him personally regarding emacs. Note: personally.
I agree on the start up time point. I don't know how slow most people's experience is, and I don't use emacs, but I really can't imagine people aren't using emacs because of a few extra seconds it takes to open your code.
To your second, rather obnoxious point: when they said 'out of touch', they didn't mean 'hasn't been in communication'. They meant he doesn't understand the attitudes/motivations/requirements of the community.
Yes and no. I need to tone it down (or leave HN, wehich is probably better).
Other people need to improve things. But this is not going to happen. An alternative to doing something is to dismiss other people's work. That's what this guy did. 'Emacs is too slow' - emacs startup time doesn't bother me, even if it did it would be down in the noise amongst other emacs irritations (or other software, heck, the amount of time I've wasted on Git...)
He dissed emacs for no good reason, and dissed stallman who I really do respect (because RMS actually did something).
I've seen a lot of this kind of destructive behaviour and I'm so tired of it. I should just leave HN if I can't contribute properly.
Edit. If I post stuff like "x != y" I will say why, with timing, or clarify with In My Experience" or something. "emacs is slower" doesn't tell me by how much or discuss if startup time even matters, so it is a useless criticism; I can't act on it. It doesn't even feel like a good-faith comment.
Switching from vim to emacs was a virtually seamless experience and a complete no-brainer... yet I put it off for years. Years before I finally took the plunge, I knew I eventually would. Vimscript is awful and although elisp isn't a great lisp dialect, it doesn't have to be great to be better than vimscript (which is abominable.) I shouldn't have put off the switch for so long. In retrospect I'm not even sure why I put it off for so long.
> If I were working on Emacs, my #1 goal would be to beat Vim on startup time-
With emacsclient, I don't think this is relevant. Concern about startup time certainly wasn't part of the reason why I put off switching for so long.
You put off learning Emacs partly because you learned Vim first. But why did you learn Vim first? Because people around you were already using Vim. Because Vim came preinstalled. Because Vim was quicker and easier to just edit a file.
Startup performance isn't about persuading fence sitters. It's about becoming the default, the option people pick without even knowing why they picked it.
In truth when I was a teenager I sat down with vim and emacs one afternoon and tried both. At the end of that day I chose vim, because I preferred the default bindings of vim. Nobody around me used either, nobody around me programmed at all, but I had read online that the pros used or or the other.
Vim might be hard, but besides jokes about "how to quit it", it makes much more sense than Emacs.
Emacs key combinations are weird. Discoverability is low. Even Vim will now tell you how to quit if you Ctrl-C it.
Meanwhile I have opened Emacs and I'm trying to quit it (spoiler: Ctrl-x Ctrl-c). Some things are actually interesting and it tries to help at first but then it goes back quickly into emacs-babble that doesn't help much.
The case for vim is simple: a quick editing of a file when you might not have a window manager up or on a terminal.
I don't see many reasons to learn Emacs when VSC, Atom or other editors exist.
> The case for vim is simple: a quick editing of a file when you might not have a window manager up or on a terminal.
That, and the power of its keybindings.
> I don't see many reasons to learn Emacs when VSC, Atom or other editors exist.
I think evil-mode, org-mode, dired, and magit, make a pretty compelling case for Emacs to fit into many programmer's workflows, even if it doesn't displace their code editor or IDE outright.
Though even setting up just those packages requires quite a bit of configuration.
> Vim might be hard, but [...] it makes much more sense than Emacs.
Counter-point: I think emacs makes much more sense. If you start it, you can navigate a file by clicking in places. It is a GUI application, whereas I think vim is just a terminal program by default?
Emacs has a little built in tutorial (Ctrl+h t) and is quite discoverable (type Ctrl+h ? and it shows you a lot of commands you can use to find out about what functions a chord invokes or how to invoke a function with a key cord). With helm you just type a part of a function and it gives you a list of suggestions.
Within programming languages I think auto-completion is a must-have for discoverability. Otherwise I have to constantly look up stuff in the documentation. And for that company-mode is really nice, I don't know about the vim side of it but I think something like that goes against the philosophy of vim as I understand it?
To me, modal editing didn't make much sense in the beginning and for emacs the learning curve seemed less steep, so that's what I went with in the end. But clearly it must be good somehow, because so many people use and love vim! It's just not for me I guess.
You're confusing vim with vi. On an IoT device I'd expect to find busybox's vi implementation. Definitely not vim. Ditto for containers, either a vi implementation instead of vim, or "vim-minimal" at the most. Not a full vim install.
Discoverability shoots up really higher than Vim or any tool when you use helm's M-x.
Also there is documentaion for literally all the key bindings and all the functions. You can access the code for all the functions. Emacs is much more user friendly than Vim.
so - your 1st point of reference is vscode which is an electron app, and then you diverge getting into emacs startup time and emacs reputation for 'bloat'
this reputation by the way was 'earned' when entire computers had less memory than a typical emacs or vscode instance, and similarly,
emacs likely currently uses less RAM than vscode due to afformentioned electron. Also: vi vs emacs 'bloat' wars were in reference to actual vi, not vim, which basically has the same non-core functionality as emacs (e.g. GUI widgets, editor-hosted scripting language) that was the basis for the original 'bloat' argument.
I agree that VS Code is even more "bloated" than Emacs, but it has a multi-billion dollar corporation funding it. If Emacs could get that, maybe Emacs would be as popular as VS Code!
But, short of that, Emacs can't beat VS Code. Emacs could beat Vim, but only by being so fast and small that it gets installed by default on Linux distros (and macOS and WSL).
But that'll never happen, because Emacs folks prioritize features over performance. (If they cared that much about performance, they wouldn't be Emacs users!)
honestly, with lsp-mode, it's pretty dang close to vscode, at least for the languages I care about. and the benefits of evil + a fully configurable editor are too much to pass up. a drop-in replacement for newcomers? no way. but if a powerful environment is valuable for you, like say if you spend a lot of time in an IDE and the shell, emacs's ability to integrate those things and a lot more is too good to pass up.
I found lsp-mode to be quite cool (recently reformatted my machine, and so decided to modernize). lsp-ui + company mode kills the input latency on any 4k display on Ubuntu tho. Input latency is now VS-Code/Atom level slow. Unbearable. Even with delay set to 0
This is much, much better on Emacs 27 with native json parsing. Once the language server is fully loaded (which can take a little while sometimes), input lag becomes insignificant again. Strongly recommend upgrading.
Thinking of switching to gccemacs for the native elisp goodness. But way too much yak shaving has been done already. I just disabled lsp-ui and lsp-company and all good.
As a regular emacs user, I can tell you that start-up time is one of the lowest things on my priority list of things that I wish would be improved.
Emacs is not vim. Emacs is not designed to be a program you open for every file. Emacs is and IDE. You open it every time your computer starts, and then you go to Emacs and find files from there. Occasionally, you'll have a file and want to look at it, and then you'll use client mode to have it open in a new buffer in your already opened Emacs window/terminal.
I do agree that this is not the way anyone starting out would use a text editor. But if this way of using it is not comfortable to you, you'll be fighting so much of emacs that you really will have a miserable experience, regardless of startup time.
Just to hammer the point home, normally if I connect to a Linux system and want to edit a config file, I would do the following: either `sudo vim /etc/hosts` or `emacs` and `C-x C-f /sudo::/etc/hosts`. I don't think too many people would run `sudo emacs /etc/hosts`.
We agree completely. Neither Emacs users nor developers care about start-up time or size on disk.
And that's why Vim is installed by default on Linux distros (and macOS and WSL) and Emacs isn't. And that's partly why people learn Vim before they learn Emacs.
Not quite. vim is installed because vi is required by the POSIX standard and vim is the GNU version of vi. For the same reason, ed is still installed by default. It has nothing to do with popularity.
Yes, we are probably in agreement on that point. We probably disagree on whether we should care about start-up time.
We probably also disagree on what exactly it means to learn Vim before learning Emacs. I've been using Vim as a console editor far before I knew Emacs existed, but I have no idea how to use Vim for anything more than basic editing. Choosing an editor to learn as your development environment (which is what I would consider 'learning Emacs/vim/etc' actually means) is unlikely to be a decision you take based on system defaults. You are far more likely to learn the editor/IDE that your mentors use, whether that is Vim or Emacs or, as was my case originally, Borland Turbo C. Alternatively, when you are experienced enough to make a conscious choice of editor to invest in learning and customizing, your criteria will be more varied, but still likely not depend that much on system defaults.
I currently use Emacs (with Vim keybindings) as my main editor, after oscillating between Emacs and Vim for quite a while. I think the biggest disadvantage Emacs has compared to Vim is its out-of-the-box experience. For me at least, I would say that learning to love Emacs takes a lot of effort, far more than it should. I think folks tend to mentally categorize Vim in the same basket, but I think Emacs is far, far worse at onboarding its users.
The Vim out-of-the-box experience is not exactly great (crucial features like vim-surround have to be installed as a plugin, for instance, in the terminal version there's a lot of delay on some commands, etc). But while learning the unfamiliar keybindings initially takes effort, the huge speed advantage of modal editing becomes apparent after just a few days of sticking with it, and it becomes second nature surprisingly fast, to the point where you just stop considering editors which don't have decent Vim emulation. So while I wouldn't exactly describe Vim as accessible, it gets its core idea across fairly quickly.
By comparison (and also in absolute terms), the Emacs out-of-the-box experience is horribly bad, it seems to make no effort to wow its first time users. It stubbornly sticks to a keybindings scheme that is unfamiliar to a modern audience and which, crucially, unlike Vim's keybindings offers no substantial productivity boost. All the documentation even still calls the Alt key "Meta". So you spend multiple days getting used to Emacs' keybindings scheme, only to end up roughly where you started (not much faster than before). At this point it's easy to start feeling like learning Emacs is not worth it: you've just spent days learning without your productivity increasing, and you just have to take people's word for it that, no, really, it'll get better. The main selling point of Emacs is its extendability. But this point is lost on users who aren't already convinced that they love and want to use your editor. You have to provide a good out-of-the-box experience still.
I love emacs because it's fully programmable. This flexibility comes at a cost though, i.e. the time invested making the environment mine; exactly how I want it to be. It's like a sandbox for text based work on a computer.
Not everyone is willing to invest this time and therefore IMO it won't be a very popular environment for most users. I don't blame them, everyone's needs and priorities in life are different.
Or you could start with a popular .emacs.d (I use Doom Emacs), tweak a few things, and tell yourself "I don't need to modify yet another key binding" a hundred times.
781 comments
[ 3.3 ms ] story [ 360 ms ] thread1: https://github.com/hlissner/doom-emacs
An an occasional user of both Excel and Emacs (mainly a vi guy), I waste at least as much time figuring out where "that tool" in Excel went or how to get in to one of the weird graph editing modes as I do with the more obscure Emacs features I use sometimes.
The biggest problems with Emacs, to me, are the rendering performance, the lack of sufficient threading, the default keyboard-accessible windowing commands, and Elisp being unergonomic and sad.
The course I'd chart for an ideal Emacs would be rendering with something like Alacritty†, some default windowing commands similar to tmux, and phasing out Elisp in favour of a Clojure dialect; the last bit would help a lot with introducing some basic sources of concurrency.
† Plus smooth scrolling surfaces, since a text editor generally does not have enough surfaces that the memory overhead of tiled surfaces is a serious issue like it is for general-purpose renderers like web browsers.
Namespaces for vars and functions being not a language feature is inconvenient. Unless you are using fakespace or intern-symbol (it seems hardly anyone does), every symbol in your program needs to include its namespace information in order to avoid it being accidentally invoked by somebody else, or accidentally convincing somebody that it's part of the base distribution.
In Clojure, it's many little things:
Keywords are callable, allowing you to evaluate a keyword on an associative collection like hash-map, or traverse, in an obvious and intuitive way, into a nested associative structure with the threading macros "->" and "->>".
The default data structures are fast (for what they are) and hard to misuse: unless you ask politely, you are not going to mutate something your function was passed passed without noticing. seq, the interface for sequences (vectors, lists, pairs from an associative structure), pairs well with destructuring in let and macros/syntax that does binding.
Things like 'let' don't use more parentheses than necessary, which has a greater impact on readability than you'd think. The use of vector syntax for bindings rather than list syntax adds a little bit of syntactic texture that makes reading programs more ergonomic.
I think Clojure may not be as unfamiliar as it seems at first to a person who's written other lisps before, but I have yet to meet somebody who prefers the experience of writing Scheme or Common Lisp to Clojure; nor anyone who prefers Elisp to Common Lisp.
[1]https://github.com/magnars/dash.el
[1]: https://www.emacswiki.org/emacs/GuileEmacs
For instance, the global namespace is great to play with and learn commands in the scratch buffer. Also the custom datastructures and generally the emacs lisp abstractions around editing are a joy to use.
I agree though that the rendering is too old fashioned. I'd love for Emacs to get smooth, animated scrolling instead of that tty-esque line-by-line movement of the text. That really makes it hard to keep track when scrolling throught large documents.
http://www.smashcompany.com/philosophy/gendered-on-ramps-are...
I've worked with a lot of Emacs fans but everyone describes it as having a hefty learning curve. If you tell people it's appealing and the first experience is unpleasant, all you're going to do is convince them that you aren't a reliable source of advice. I think it would be much better to focus on easing that initial stage and explaining it a powerful tool which requires some up-front investment.
And I'm not saying lie. Just stop scaring people away. Emacs is by far one of the most empowering programs out there. Market that.
She realize that it is marketing. You want to build a market of users? You have to have some marketing.
I'm not saying to merely claim it and call it a day. I'm saying claim it while showing people how to use it. Make it a dialog that doesn't begin with, our way is harder. It isn't harder. Just different.
If I start emacs, I can navigate around the text with the arrow keys, the way I would expect from most other text entry systems. Then I can just type stuff. I can click at points in the text to navigate there, just like in notepad or anywhere else.
OTOH in vim it is nothing like that. Nothing is even remotely familiar. Yet there are much more vim users than emacs users. So I don't buy it that the learning curve is the problem.
That’s seriously begging the question — I mean, there’s a pretty popular running joke about quitting vim and it’s been many years since I’ve heard any recommend it as easy to get started with. In the 90s people suggested it due to Emacs hitting memory constraints but most CPUs now have more cache now than those computers had.
I'm sorry to react to first quote, but as I kept reading I kept coming back to it. My thoughts on that : how you present yourself is how you want (and are going) to be judged.
In general I think Emacs has been user-hostile, as said here, just by its terminology. Nobody outside a minority of devs (a minority even among programmers) refers to Ctrl+c as C-c.
> Yes, make Emacs appealing and user friendly. But don't forget that a masterful tool in the end requires mastery, which can't come for free.
And the old "I have suffered therefore the others have to suffer".
First, C-c is not Ctrl + c; second, it really helps to use compact notation when you read a lot of keybindings; and third, this is approximately the most minor complication in the learning curve of Emacs (otherwise nobody would learn vim, with its insane key mappings and invisible mode transitions).
Words once written don't need to be abbreviated. Abbrevation is only useful when writting for speed. When writting for being read don't use them.
No, you're just being ignorant, and not reading when people try to answer your questions.
> Abbreviation is only useful when writing for speed. When writing for reading, don't use them.
It's not an abbreviation, it's a different symbol. C is not Ctrl.
The software has some “baggage”, being the heir to a 40+ year legacy, but the problems you're ragging on are so shallow that it just tells me you never tried. Why would anyone want to continue holding the hand of somebody who isn't even trying?
Emacs is full of excellent documentation, the first thing it tells you when you open it is how to find the documentation, and if you have a mouse you can just click it; if you opened it and decided not to read the intro, but somehow a lot of other people are using it productively, maybe the main problem lies with you.
If you're looking for a piece of software that'll give you some sort of religious aesthetic orgasm just looking at it; sure, you'll be let down. If you were trying to get something done and approaching it honestly, these would not be your complaints about Emacs; trust me that there's a lot wrong with it. Having its own slightly different keybinding notation is like... number five thousand on the long list of actual issues with any honest attempt to be productive with Emacs.
Emacs interface and community mannerisms _are_ user-hostile. As demonstrated by history.
There are lots of things that seem daunting at first and unforgiving to the impatient beginner: chess, surfing, martial arts, drawing... it doesn't mean that any of those are user-hostile, it just means that those that want to learn and master it will need to develop a certain discipline.
If you don't want that, fine. But what is the point of going around and saying that those who do enjoy these things are stupid?
I think the expirement is over and conclusions can be drawn : emacs represent a tiny proportion of text editor's users, not because of a lack of features (is there's one thing missing it won't be for long), but because of what it is and the people and community around it.
It is also a bad misrepresentation of the point made by the person that you originally quoted.
Let me try an analogy: emacs is Olympic-sized pool, 50m long, 5m deep, with a 10m jump platform. It has been in use for decades by all kinds of people. Some new people see some amazing swimmers and divers using that pool and want to join. Problem is, they also don't know how to dive and are still learning to swim so they ask for a nice ladder on the corner and they want the pool to have one end shallow enough for people to stand on.
The developer is basically saying: yeah, getting in there is intimidating at first and we can do some improvements to help beginners, but we also need to find a way to get those beginners to get into the training program, train harder and dedicate themselves to diving, otherwise it would just be a waste of time and resources. Oh, and we also need to keep in mind that none of these changes should affect the people that are already training here for years.
I'm not saying that Emacs users are better than you, I'm saying that you lack the experience to judge the value of Emacs; and that your lack of experience makes your assessments of Emacs basically too shallow to contribute meaningfully: in short, you don't know enough about Emacs to tell if your dismissal of it was premature, or if the things that turned you off were just the unfamiliar tail end of a coherent system.
It should be obvious that there are many many people who have spent more time actually using Emacs than you, and almost none of them by force or by fiat: literally nobody asked me to use Emacs, nobody started me using it, I received little or no assistance in learning it, I was mocked for using it as a teenager, and I spent most of my time with Emacs on teams of droves of people who do not use Emacs and evangelize other editors. At the outset, I simply wanted to try it, and I gave it a fair shake; I continued to use it because paid off for me.
The fact that people willingly start, and continue, using Emacs of their own volition with no external help or encouragement, should tell you that there are merits to the program that outweigh the things that turned you off before you gained any meaningful understanding.
C is an abbreviation for <Control>. You can map pretty much any key to any other key, that’s neither here nor there. M is for meta, s is for super, S is for shift, A is for alt, H is for hyper.
My control key is mapped at the window manager and terminal level. As far as emacs is concerned it’s control. If I map my R key to emit a control key code... C is still an abbreviation for control.
But if we're going down that road, M is for alt really, and super wasn't always what Xf86 says it is (the windows/command key).
The mapping of keys is arbitrary, but the bindings to the symbols are documented and many defaults exist.
Your writing implies that Emacs is something like the notepad of Ubuntu. But it’s history is much more extensive than that—- which happens to be one of its unique selling points.
Anyway the point regardless of historical context, is that for all sensible people, that capital C is being used as an abbreviation for the word Control. You’re just being a prat correcting people. You’re not even technically correct, you’re just wrong.
I find it harder to scan my eyes over Ctrl+Alt+a than C-M-a (notice that Apple, too, uses single glyphs for modifier keys).
It's written in most emacs documentation as C-c for brevity.
Things like C-c C-v are chords. <Ctrl+c> and <Ctrl+v>.
I might be wrong, but I believe that the reason that parent commenter said that "C is not Ctrl" is due to the fact that you can map these keys to any where you want. Most emacs and lispers prefer to have C key bound to caps lock.
Yeah, but it's still a control key. I mean, xev literally registers "Control_L" when I press the key that is physically labeled "Caps Lock".
Discussions about terminology are totally secondary, and honestly, I was just trying to find a polite way to show that I don't want to get into an argument about terminology.
Actually, its an extremely important point. Tools which optimise for the professional are better than those which do so for the noob. Whenever you can achieve both, do so, but never side with the beginner otherwise. People should learn their tools, and they shouldn't be beginners for long, so making things "friendly" at the cost of rewarding expertise is poor design.
Using conventions like "M-x" throughout the documentation, even with a note at the front of the manual that "We refer to Alt as Meta for historical reasons.", is needlessly baroque. Worse yet, maintaining a distinction that those aren't effectively the same thing for almost all users is needlessly unhelpful. (Yes, it's possible to make Alt and Meta different keys under X with use of modifier maps. That explanation belongs in an "advanced keybindings" chapter late in the documentation.)
It's certainly possible to learn that, and a hundred other gratuitous weirdnesses, but they don't actually add value that justifies imposing that weirdness on every user.
> if you can make a tool more learnable for new users without sacrificing its optimization for power users, you should
Yes, but it's incredibly difficult and frankly the emacs devs have enough to do (and they do it well), and UI design is a very different skillset from programming. Frankly the learning curve for emacs is not going to improve, muchas we both might wish it.
The biggest problem is people want the benefits of freely downloadable software but mainly aren't prepared to give anything back. Go and assist with emacs or some other project.
I don't really buy this line of argument in general, but I think Josh is a particularly poor candidate to pull rank on because they don't contribute to open source. I don't know Josh, but I recognize his name from his open source contributions.
If you don't recognize Josh's name, you can get an idea of some of what he's done from his website, which is linked in his bio: https://joshtriplett.org/
> I work on Linux, primarily on the RCU subsystem and on Sparse-related code. I maintain the rcutorture test module.
> I co-maintain the X C Binding (XCB). I developed the XML-XCB format to describe the X Window System protocol. I also work on other Xorg projects on Freedesktop.org.
> I maintained the Sparse semantic parser and static analysis tool for C for several years, before passing it on to Christopher Li.
> I maintain several packages in the Debian project.
Ah shit, I recognise your name too. I've just been spanked by Dan Luu. This has not been a good night.
I have a freaking book to write...
Right. I see this point ignored very frequently (sometimes because it's obvious and sometimes because people are being dumb).
A lot of the things that would make emacs more like other editors are extremely difficult to retrofit. I expect there is still SOME low-hanging fruit, but a lot of the low-hanging fruit has already been picked, and a lot of the remaining changes that people would like are a lot of work.
BTW the current key bindings are so good because I can do a lot without my hands leaving the keyboard, or even moving off the home keys. That was the very point of choosing them originally AFAIK. I recall learning these new keys many years ago, it was surprisingly fast and when I'd learnt them, amazingly quick to sink into muscle memory.
Each modifier can be mapped to any physical key. For example, I'm one of those control as caps lock people you mentioned. I then have hyper on the left control key, alt and meta (yes both) on the left alt key, level 3 on the right alt key, and compose on the right control key.
Rereading my previous comment I've realized there are some slight inaccuracies - keybindings are conceptually a bit complicated (at least under the historical X11 model). My Alt keycap actually just produces the corresponding Alt keysym, which maps to mod1. My confusion was due to the Meta keysym also mapping to mod1 (this is the default configuration) even though no key on my keyboard is currently configured to emit it. I set everything up quite a while ago and then forgot some of the details.
* Caps Lock -> Control: This is simply more comfortable for frequent use, particularly in combination with the Vi directional keybindings (hjkl).
* Right Alt -> Level 3: AKA AltGr, this is useful for entering common Unicode characters.
* Right Control -> Compose: Useful for a number of other Unicode operations. I don't seem to make much use of it in practice though.
* Left Control -> Hyper (-> mod3): I had a free key. This gives me an extra modifier for use with things like my window manager that's pretty much guaranteed not to conflict.
* Shift + Space -> Underscore: Makes C programming _way_ nicer.
* AltGr + Space -> Nonbreaking Space: I don't actually remember why I configured this one. I never use it.
* Shift + Shift (ie left & right) -> Caps Lock: I don't actually use it, but this way it's still available.
I don't think Emacs has done itself any favours by using obscure and non-standard terminology based upon machines from the '70s which few people have heard of, let alone experienced. For the vast, vast majority of us, we all have bog-standard PC or Mac keyboards, and have done for the past 30+ years. It would have been in everyone's interest to standardise on terminology and keybindings which were immediately understandable and usable by all.
Given that every other application uses the standard terminology and keybindings, and that I don't see much in the way of compelling advantage to keeping the non-standard bindings other than habit, I think preserving backward compatibility for four decades was laudable but misguided.
I suppose that cosmetically they could update the documentation by changing M- to A- or Alt- or something. Would it really make a difference though?
Aside: Not meaning to be pedantic, but at least under X11 Super is the "Windows Key" and Meta doesn't exist by default. I just checked and (on my machine) the keycap with the Windows logo maps to X11 keycode 133 (hardware specific) which produces keysym Super_L at both levels 1 and 3 which in turn maps to mod4.
In the Rust language design, we're careful about what we spend our "weirdness budget" on. We've already spent a fair bit of it on terms related to ownership and borrowing, because those are fundamental and central to the language. We spent some on having a one-character '?' operator for error-checking, because error-checking occurs so often. But we're not going to gratuitously introduce new vocabulary for existing concepts that already have a name people would be more familiar with, and we're extremely hesitant to introduce gratuitous syntax abbreviations just so people can type a little less, because they'd be harder to read and understand.
That said, as someone who very slowly got into Emacs and now am full on into it, all this weirdness slowly became more of a an, oh this actually makes a lot of sense, and, you know what, I might like it better.
I still find it weird for a frame to be a window and a window a frame. But logically, I think the Emacs names make more sense. The thing with a frame is a frame, and the sections within it are the windows. I wouldn't mind if it was renamed frame to window and window to panes tough.
Similarly, C-c and M-m used to confuse me a lot. But now I find them way nicer, why have to type all of Ctrl and alt. Also on Mac alt is called command, so having a Meta as a more generic name for the key kind of works.
Kill was weird to me, until I realized kill and delete both exist, but behave differently. There's a kill-ring, text that is killed go in it, text that is deleted doesn't. When you program extensions this is a very important distinction. You don't want programmatic edits to all go in the kill ring and polute it.
Would it be nicer if the more common user used one, which is kill, be named delete which is more familiar to people maybe.
Like I said, I wouldn't mind someone making a big refactor of it all and renaming everything to be less weird to modern times, but I think as you learn those "weirdness" they stop being weird.
Basically, I mean there's a big difference between a quirk, and just something you're not familiar with. I think Emacs names are mostly unfamiliar.
Emacs also has real quirks though, and I think those are more important to address. Like there's a lot of legacy cruft, having to still support working on defunct terminals, and all kind of stuff. Like ESC being a weird Meta key because of terminals that don't support meta. Or the entire UX which is crap by default.
In emacs, I have absolutely no idea how to discover features, and if I find something I still have to understand what the M- and C- mean
The built-in "help" functionality[1] is really great. C-h a will find useful documentation for what you need 90% of the time, and the manual is there for most of the rest. It's particularly useful for keybindings - C-h w for "what's the keyboard shortcut for this command" and C-h k for "what command does this keyboard shortcut run.
[1] https://www.gnu.org/software/emacs/manual/html_node/emacs/He...
Today's users expect different things than users did in the 70s (who expected different things than users in the 80s, 90s, so on). Emacs has been relatively consistent through time, which has been a huge boon to emacs users. The tradeoff is against current user's intuitions -- for better or worse, emacs does not work like other popular software today.
Calling this "user-hostile" comes off somewhat entitled. Emacs developers in the 70s/80s/90s/00s simply didn't know enough about today's users to cater to us, even if they wanted to. That's hardly their fault.
So, todays way and the emacs way have diverged some, and it does take a bit of effort to learn. Not because emacs hates you! But because emacs is ancient. The (objective, non-stockholm-syndrome) reward for your efforts to understand it are a) mastery of a system useful enough to survive this long, and b) mastery of a system that isn't likely to change out from under you.
We can acknowledge Emacs's longevity without straying into unsupportable hyperbole. Emacs is nowhere close to unprecedented in its age and not remotely close to the oldest piece of software still in existence.
GNU Emacs is from 1984. It is a reimplementation of the earlier 1972 Emacs. This matters, since if you're including reimplementations then obviously Unix itself, which is used by many of us every day, it older. And if you start counting from 1984...that's not especially old.
I pointed out emacs' age to note how users expectations of editors have evolved over that time. Certainly there is older software -- but is there any other user-facing software that has survived such a dramatically shifting landscape? That is the part I find unprecedented (and the part relevant to GP).
Yes. Microsoft Word, for example, is older than GNU Emacs.
Cars from the 70's don't have airbags. So, by comparison to what is available today, they are user hostile.
Maybe better: "Old" (pick a date) cars had a manual transmission. Compared to automatic transmissions, you might consider that user hostile. But back then no one knew what they were missing and got along just fine.
Nowadays, some people still like manual transmissions! Not everyone, but some folks still buy them. Some even claim they're better than automatics! "They're cheaper, easier to maintain!" Are they user-hostile? I guess it depends on who the user is.
(Airbags seem like a strict improvement, sure. But part of that comes from them not being part of the "interface" of the car -- we don't interact with them, we don't form preferences about them, gain familiarity with them, etc. Perhaps they correspond better to multi-cored CPUs, multithreading, or high-res color displays (features emacs has kept with the times on, more or less). It's much harder to come up with similar strict improvements in the UI world.)
I seem to recall reading that the keyboards that emacs was originally developed for had the CTRL key in the middle left (where the modern, useless, "caps lock" key is). The awkwardness of the CTRL key on modern keyboards makes emacs seem unnecessarily user-hostile as well, but that's also not something that Stallman could reasonably have predicted.
It also takes what, five minutes to get accustomed to? Even old dogs can learn this new trick.
So it's not user-hostile, it's just really old. The knee-jerk answer would be 'well just update the conventions/terminology'. The problem is, update it to what? There is no timeless terminology they can use. As the tech industry increasingly resembles the fashion industry, they'd need to slap a new coat of UI paint on it at least every 10 years to keep up... as what was 'user friendly' terminology today won't be in not too many years. So now the developers are spending a big chunk of their time 'modernizing' it rather than actually making it better... not something most developers are interested in doing for a passion project.
Perhaps an example will be more vivid. In the eighties most people who were on the internet worked on a 24 line by 80 column terminal. Some people used Emacs buffers as a predecessor to multiple windows on large screens:
- Edit your code, perhaps splitting the screen in two buffers to look at different files or places in a large file.
- Split yet again one buffer for compilation error messages.
- Split the other one for a shell subprocess to run the program, check mail, etc.
Basically all-Emacs all day. Not my setup, but I saw it done often enough.
Expecting people to adapt to 1984 - which, just a reminder folks, is more than 30 years ago - rather than updating your documentation and maybe some keybindings to better reflect today is in fact incredibly fucking user hostile.
I don't agree. It requires a bit of learning if you are used to something else.
>I have suffered therefore the others have to suffer
This isn't true. Try, instead "I put some effort into learning it, and you can too."
Deeper understanding leads to higher productivity.
seriously though, it's a rabbit hole. Been there myself, now I just us vscode and it's a breeze!
(As another example where *nix systems could improve a lot, the Midnight Commander tty app is great, but still not quite as intuitive as the old 'DOS Shell'. Weirdly enough, I find that other TUI apps, such as dselect and aptitude, are quite outstanding but you do need to be on a Debian-based system - they aren't a thing on Fedora or CentOS.)
They may be easier to learn (since they have pretty minimal functionality compared to Emacs) or easier to discover when you are new to them but they are definitely not easier to use. I use Emacs not because I am some kind of masochist but because it is the easiest way to get my stuff done.
Which modern editor has tools like SLIME or CIDER?
(2) There's no better environment available for dealing with text (including notes, papers, slides, email, &c.) than Emacs.
Why do you hate future programmers so much?
Your second point is very subjective and most people are bound to disagree with it. You certainly can't argue that like it's an objective fact, because it's very much not objective.
It makes perfect sense as soon as you realize there is no reason the cursor has to be the cursor. In curses: curs_set(0); then draw your own 'cursor' wherever you like.
Anyway, GUI emacs is way better than terminal emacs. Image support (in terminal emulators this is always an awful hack) and support for different font sizes in the same frame at once is something I'd not give up.
That's far from obvious. I recall terminal interfaces rather fondly. Modern interfaces are often more like a flock of multi-colored rabid weasels trying to get in the way of my work.
I'd have loved to have been able to give magit a go.
I do still have Orgzly on my phone though.
Accessibility feature in macos where modal / control keys will "stick" for the next keypress (non-modal / control) and then release.
Double tap will stick it for the duration until the next tap on the same key.
Essentialy, double tap control key and move around with n and p keys, kill with k, move more, yank somewhere else with y. All without touching control! But there's more, you can save the buffer with x followed by s press. It takes a while to get used to but saves you awkward wrist moves. I guess it's closer to modal editing in vi, just not as advanced.
https://github.com/emacsorphanage/god-mode
As a user of these key binding in both Emacs and macOS, it’d be worse than cutting off an arm if this went away
Or all movement combined with prefixes. I regularly do
to jump sixteen lines backwards. Or add another prefix and it's 64 lines.Separately, macros, yea! Macros with regexes FTW! The counter you can use in macros - occasionally very useful! M-x occur! Dired which can search a whole directory tree of file contents for a regexp! So much more.
Only thing worse than emacs interface is not having emacs at all.
Every time I work with Linux or Windows, when I open a Chrome tab and I want to go down to a history completion, I hit C-n multiple times and it ends up with many new windows...
Of course, emulating the shortcuts & functionality of Word and Photoshop shouldn't be considered a problem, we are talking Emacs here after all...
But any arguments regarding word editing in latex markup I won't accept.
Emacs already have a concept of frame, and you can already configure each frame independently (e.g. for term and X), all connecting to a single Emacs process, and can share buffers/yank ring/etc. across multiple frames.
Emacs is built on a philosophy of human nature that deemphasizes the subjective personal experience in favor of (a limited group of people’s theory of) the objective ideal experience.
In a short amount of time, VSCode and it’s ecosystem has almost equally matched what Emacs and its ecosystem took 30+ years to create.
I'm not $o $ure that'$ actually a$ impre$$ive a$ it $ound$ ;)
The vast majority of Emacs's usefulness is its ecosystem. Several Emacs clones have been made in a very small amount of time, but none have caught on because they lack the ecosystem and community. So it's only really fair to compare VS Code's ecosystem with Emacs's ecosystem. And VS Code's ecosystem was created by unpaid volunteers too.
Unless we do, emacs will slowly die.
No one wants that, neither RMS nor any passionate emacs user including me.
Emacs tries very hard to be helpful. It's software by the people, for the people. It's the very core ideal of free software. But yes, it doesn't resonate with most people because it takes time to learn.
At the same time, if we compare emacs to vscode, vscode simply requires less configuration to get going. Given how much tooling exists in the javascript ecosystem, I think having a few plugins "just work" goes a long way.
Asking users to configure emacs from scratch to have a reasonable editing experience in their programming language of their choice is a lot. I think configurations like doom or spacemacs do a lot for this problem, but it really comes down to marketing.
True, but then why do more people uses Vim than Emacs? Is it becase it's installed on servers and stuff?
I wonder what percent of desktop programmers use vim or emacs who don't need to do devops.
I could probably switch to Emacs using Evil, but I don't see a compelling reason to.
Having all of Elisp and all of Emacs available, including packages, is powerful. But it comes with a complexity cost if your config/dependency graph grows to large. Like any in-house software project really - of which a small business cannot afford to invest in.
There is one area, though, I’d use it again for: Lisp. Clojure with CIDER, CL with SLIME. As far as IDEs go, the level of language support for Lisp is phenomenal and without equal (but not surprising given Elisp).
But the benefits out weigh the sluggishness I feel at the keyboard. It was easier to get the rest of the team on VS Code and then I could start looking at extensions that bring things as close to what’s in Emacs as possible. That’s improved team productivity as whole (and my own when they do the same).
But there are somethings I long for. Magit was hands down the best thing for projects versioned in Git. I’ve not seen anything like it in VS Code. The other thing is macros and Elisp but as above that’s a double edged sword. I’ve actually thought about bringing some of those ideas over to VS Code at least for my own team.
I use emacs because I can't imagine using anything else that has half the features and is harder to extend. I can't imagine why it needs to be popular. It's a programming environment that happens to have a text editor built in. That appeals to some folks but I can't imagine why someone interested in writing for publication would choose it over Scrivener or a word processor and why it's desirable to attract such users.
If I had a horse in the race I'd focus on the developer experience. Make it easier to extend, make the runtime faster (the native compilation stuff is super cool), better unicode support, alternate input methods, etc. If people want to use it for publishing it should be easy to write a package to cater to those users.
For me, a long time emacs user, I think the biggest concern I have is ensuring that the project is sustained by new developers.
I'm mostly satisfied as a user. I'm working on a mode for editing emojicode[0] and it's a weird edge case but it'd be nice if emacs worked out of the box with nice defaults for this sort of thing. More experienced library authors might have more to say about it.
[0] https://www.emojicode.org/
What makes you say that? I don't think this is true. Not among the package maintainers anyways, and also of note here is remacs - I can't imagine greybeards programming in rust.
And popularity does not always mean more contributors, not when they are just the consumers of the product. The drop off in delta contributors / delta consumers is fast.
I was talking about the "core developers" who work on the emacs core, not packages. AFAIK most of them has a long history with emacs, using it for decades, so they can't be that young.
But of course I know mostly about the maintaners and stuff. It's possible there are lots of younger contributors.
Why not?
the same thing that probably made you say this :
>I can't imagine greybeards programming in rust.
emacs is an older software package, from the 'original home of hackers', extended in a (sorta) language that is notoriously connected to old-school AI and academic programming. The holy war of vi vs. emacs has raged for decades -- and emacs/vi/lisp jokes are some of the oldest computer geek jokes in existence.
I can imagine the fans skew older then say fans of something like Electron or Flutter.
The only computer-geek-joke-theme that I can think of that'd be older would be the billions of COBOL jokes -- but that's just because i'm too young to have heard the billions of punch-card and wire-routing jokes that inevitably existed before I was here.
>the same thing that probably made you say this :
>>I can't imagine greybeards programming in rust.
Guilty. I clearly had a blind spot there.
I'm pushing 50 and excited about Rust because it's finally conceivable to have software that works reliably. I like Emacs, but it's not like I haven't seen my share of crashes in its kinda clunky C runtime. Hell, Rust even has macros.
Care to elaborate what you mean by that?
it's a fact of life for developers with projects anywhere near the GNU-scape that if you don't GNU it, you'll catch a lot of hatred, even worse if you choose to avoid licensing all together -- and gods help you if you choose a tongue-in-cheek licensing agreement like WTFPL.
at the end of the day a lot of people just want to contribute meaningfully to a project that they use and enjoy, but the headache of licensing and catching flak by choosing the wrong one (and since all the communities have opposing thoughts, they're all the wrong one to certain folks), it just becomes easy to 'forget to contribute' -- especially when your patch or whatever is working fine locally and there is little practical incentive to catch that much heat.
I think the legalese issues turns a lot of would-be contributors into local-patcher type developers, and then they leave for greener pastures once what they needed patched is on their own machine -- especially for projects like emacs where 90 percent of development is going to be towards extensions.
...and I say all this from a position of love and admiration for GNU and the FSF.
But (some definitely not all) folks are pretty all or nothing. There's a lot of jerk developers on the net though, maybe it's better to just ignore them?
As for contributions, presumably GNU wants ownership, but do they have a problem with assigning back what amounts to public domain rights to the author?
And I suppose, for most contributions, does it really matter? The awful truth is that I can't think of anything I've ever written that had freestanding value, as opposed to value as an enhancement to something else.
I don't know about that, I hate agendas. A hammer does not have one, and that does not make it a less useful tool.
Sure, but by default all software has a copyright agenda built in. We can remove copyright, but there are two approaches:
- Remove copyright so that anyone can use your code, but then they can re-add copyright to your code and sue other people for violating their copyright.
- Remove copyright so that anyone can use your code and ensure that nobody can re-add copyright to your code.
I used to be in the former camp, but I've slowly moved to the latter.
I see why you might go with Apache, or MIT, or even straight public domain licenses. But as a maintainer, I would not accept a contribution which is not properly licensed, or which is licensed in a way not compatible with the project's license. Usually such a contribution is less valuable than the rest of the project, so there's no point to introduce a real legal risk of project's closure for the sake of such a contribution.
For those who just want to bury their head in the sand and pretend copyright doesn't exist, they will be the first to complain when the code that they wrote is taken private and commercialized (i.e. look at the licenses this has been an issue for)... making code 'public domain' allows for that.
I don't trust the FSF further than I can throw them and I don't trust them with my copyrights.
I spent 20x more time back and forth on copyright assignments, including getting a release from my company, etc to get the patch in. I pushed through because I felt like I was always "just one more yak shave away from finishing", but if I knew at the start how much time it was going to take, I'd have kept the patch on our own private site-lisp. That's a problem, IMO.
Just something to note.
TBF, given the historical FUD baggage, I don't fault them for trying to play extra safe as stewards of the project. Also, Emacs makes it so easy to get packages out-of-band (eg: MELPA, Borg, Straight, Quelpa) that I don't think the copyright assignment is a big deal unless one wants to get code merged into base Emacs.
People live as much or more in the browser as the terminal these days, so bring the emacs sauce to where the people live. Maybe you could get some of the c compiled to web assembly, and the lisp would follow? It'd be neat to open a buffer to the page emacs lives in and start editing, call JS code, or embed emacs into a page as easily as monaco. Maybe the GUI components could be made out of HTML 5?
1. https://techcrunch.com/2020/05/06/github-gets-a-built-in-ide...
PS. Rough sledding for Gitpod with this announcement.
I'm not very familiar with how easy it is to capture browser keybinds in a web page.
[1] https://chrome.google.com/webstore/detail/secure-shell/iodih...
Neovim literally has like over 30 projects for new UIs:
https://github.com/neovim/neovim/wiki/Related-projects
http://www.ymacs.org/
I see some other good ideas here too that could maybe give emacs a fresh breath in the new world of IDEs in the browser/cloud.
Emacs Lisp is the reason for Emacs being such a cohesive ecosystem. JavaScript would be a major mistake.
Color me surprised! I'm turning into a stereotypical Linux greybeard but I must be true to my nature, and endorse Linux for writers.
There's this famous story, about the secretaries who mastered Emacs and preferred it to the other 'easier' administrative programs they were offered.
https://groups.google.com/d/msg/gnu.emacs.help/QU6xN34ollo/K....
"Shel wrote Mailman in Lisp. Emacs-Lisp… Mailman was the Customer Service customer-email processing application for … four, five years? A long time, anyway. It was written in Emacs. Everyone loved it."
"People still love it. To this very day, I still have to listen to long stories from our non-technical folks about how much they miss Mailman. I'm not shitting you. Last Christmas I was at an Amazon party, some party I have no idea how I got invited to, filled with business people, all of them much prettier and more charming than me and the folks I work with here in the Furnace, the Boiler Room of Amazon. Four young women found out I was in Customer Service, cornered me, and talked for fifteen minutes about how much they missed Mailman and Emacs, and how Arizona (the JSP replacement we'd spent years developing) still just wasn't doing it for them."
Hell, there's even a 1-hour series on YouTube called "Emacs for Writers."
https://www.youtube.com/watch?v=FtieBc3KptU
Spoiler: I skimmed it and it's as I thought - it's largely about Emacs and org-mode. Honestly, I can't argue with the classics. Here's my pitch.
Writers of the world: You are information workers. That means you have problems with the organization of information, probably, and - related - information overload.
Let Emacs help you with this!
It has a mode, org-mode, which is usually overcomplicated, but is basically as simple as markdown (no, really). Has anyone ever walked away from Markdown because it was too difficult to understand? Probably not. It doesn't have to be any harder with org-mode. In fact, in the next two lines, I'll teach you about 95% of how I use it - everything, in two lines.
* an asterisk before a line makes it like a sublayer of the layer/line above it; if you're on a sublayer, add another asterisk to make a sublayer of a sublayer, and so on ad infinitum...
* press tab to expand a layer or a sublayer you are on; press tab again to contract or hide it
That's it! That's 95% of the value of org-mode right there. It's the simplest way to organize information, in my experience.
Now, there are other advantages too, like: Emacs works with plain text, and plain text is super portable (everything can read plain text), fast to load, and can even be a convenient method of organizing things, if you give your files descriptive names and learn to use 'ls' to list things. Because those files are plain text, they take up almost no space, so it's fine if your computer has a zillion of them, it'll be blazing fast.
I could go on, but these two things alone make Emacs worth your time, and there's plenty of other advantages, like using LaTeX to make PDF's, you can 'grow into' also.
Is it possible to recreate some of this functionality in emacs? Definitely. But, it requires a lot of patience, exploration, and determination.
Your editor wants to add track changes and inline comments to your manuscript draft. How do they do that in your org-mode file?
You've received a .docx draft from a friend, or copy for your book blurb, or a press release for your upcoming publication. How do you edit that .docx and return it in better shape than you found it?
You're writing a novel, and it has extensive research notes, background material, and miscellany you're keeping track of. How do you quickly navigate between these multiple sources of content, marking things up, merging different aspects of documents?
I'm a die-hard emacser, and I do a lot of personal and academic writing in LaTeX. But honestly, have you ever had to reformat a LaTeX manuscript for journal publication? It can take hours just to get the damn file to compile.
emacs is worth the time, if you're inclined to tinker and invest the effort to get it to work—but for me, at least, that's a hobby. It's disingenuous to present it as a real competitor to industry-standard workhorse word processors. And most writers with a day job can barely find time to write, "investing time in emacs" is a nonstarter for getting things done! In fact, I tune my own org-basaed PIM system as a way to avoid getting real work done...
https://orgmode.org/manual/Comment-Lines.html
> You're writing a novel, and it has extensive research notes, background material, and miscellany you're keeping track of.
https://orgmode.org/manual/Tags.html
https://orgmode.org/manual/Internal-Links.html
https://orgmode.org/manual/External-Links.html
https://orgmode.org/manual/Handling-Links.html
Look, again, you're preaching to the choir—I use emacs every day. But writing a Python script to generate my org-native ToC to navigate reference materials is just...a very different, more work-intensive beast than an interactive drag-and-drop IDE tailored to the needs of professional writers. Impossible to approximate, with enough determination? No. Possible to start using intuitively within the first 15 minutes? Also: no.
[1] https://insights.stackoverflow.com/survey/2019#technology-_-...
"Open my doc in notepad or any other text editor. Put comments wherever you want; if you'd be so kind as to put them on their own line with a # at the start it would save me some time."
Easy peasy.
The beauty of org is that it's just a text file. You don't need Emacs to edit it.
I too have used Emacs a lot. I’m getting off the boat.
If you're git-savvy it's even easier to merge the comments in by using Magit and reviewing the changes individually.
They're all extensible enough such that emacs has no real major advantage IMHO. They can be extended with mainstream languages that many programmers already know, instead of an idiosyncratic lisp with no practical application outside of emacs itself.
Emacs still has some great modes (like tramp) - but overall, I don't think its customization is really a special killer emacs feature anymore.
Emacs has a lot of flaws though. I don't really recommend people using it. Even after showing the neat stuff, I can do with it.
Can't see how. It's hard to be easier to extend than being able to just wrtie a line of code in an init file, do M-x eval-region on it, and be done. You can extend Emacs 100% through ad-hoc manner, and none of that requires any extra infrastructure. I don't think VSCode or Atom are approaching anywhere close this level of flexibility.
Yes.
> I use emacs because I can't imagine using anything else that has half the features and is harder to extend.
Maybe imagine harder or (just an idea) stop imagining and see the real world?
> It's a programming environment that happens to have a text editor built in.
Read the history of emacs again. It originated as a set of macros over TECO to make editing easier (hence the name emacs). Editing is always the primary function, the lisp interpreter was an afterthought.
> That appeals to some folks but I can't imagine why someone interested in writing for publication would choose it over Scrivener or a word processor and why it's desirable to attract such users.
Read the linked thread again. One "such user" is RMS. That pretty much has been his goal since the 90s to make Emacs a better word processor.
This isn't to say that the keybindings never made sense; in the stage of computing before X, where Space Cadet-like keyboards were common, it was more than fine.
Currently, though? Entirely different era of computing.
Imagine you're walking in with no clue. You haven't heard of any of the memes, someone just recommended you a text editor. "It's really good! You'll be more productive!" You have no idea what in the world evil is, or why you would ever want it.
You launch the tutorial/tour/whatever it's called and immediately it yells at you to use C-v to jump to the next page. And then M-v to go backwards! If you're a normal user, your response is probably something along the lines of, "Like, why?"
Off to a good start, breaking the most universal keybinding across modern operating systems in the strangest way possible, and not only that, but also breaking one of the biggest implicit rules of keybindings.
You read a little bit more and eventually get to cursor control. Wow, somehow they managed to pick the only possible thing less intuitive than 'hjkl'! Not only that, but it's not even consistently unintuitive!
And that's not even getting into the obvious problems that come with the placement of M and C on modern keyboards.
There are a few solutions to this, obviously, but good luck trying to find a solution that isn't universally-hated.
You could make evil the default. Controversial and only slightly helps the barrier to entry.
You could make it like the Web's model of text-editing but with quality-of-life enhancements. I think this one is probably the winner. It's definitely why Sublime/VSC/Atom won, past everything else.
The Turbo C/Wordstar approach was cool, but has no mind-share today.
You could try something new, I guess? This is dangerous territory, though.
I have no idea what the solution is, but the problem(s) seem obvious. I say this all as a person who really likes Emacs. I even still have most commands memorized despite not having touched it for years now!
The hardcore emacs users think these keys are better. And don't want to change them, because then they had to rewrite the whole manual which uses these keys.
The user don't have to use these keys, though, so there is no point in the tutorial starting with them.
https://www.gnu.org/software/emacs/tour/
http://www.jesshamrick.com/2012/09/10/absolute-beginners-gui...
https://www2.lib.uchicago.edu/keith/tcl-course/emacs-tutoria...
I've never tried emacs in large part because I've been convinced over the years that the various combinations of keys I would need to memorize are too complicated. I just did that search thinking that maybe I'd been mis-remembering, but no, that's still the impression that I have.
Perhaps I am doing something non-optimal in my process. Curious how others learn/get productive in their respective IDEs.
I did learn vi years ago, but I'm sure I still don't tap but 10% of its power, despite using it daily, precisely because the key combinations seem arcane to me.
I am having trouble finding that in your long comment. The initial experience of using vi and emacs are hardly different in some fundamental way so either being unintuitive seems like a poor way to explain their respective popularity (or lack thereof).
The initial experience of vi is that you learn six keys to press to make it do things, and go from there. Emacs is significantly more complex than that, starting out.
It's definitely not intuitive, but it's an order of magnitude of difference from Emacs, which could be described as anti-intuitive.
It's strange to be talking about the UI details of vi/emacs (both, by current standards, about equally super-weird) when the article itself is a kind of perfect vignette of the organizational dysfunction of the group that maintains emacs.
The thread on the mailing list was basically guesses as to why Emacs has lost popularity & methods of regaining it, and the lwn article is primarily focused on just relaying it. The thread itself doesn't point to all that much dysfunction, in my opinion.
If that means that you can press letters in they keyboard and see them appear in the screen that’s also true in Emacs... and you don’t even have to press ‘i’ for things to start working as expected.
In vi if I press "i" I can't use the arrow keys to navigate the text as normal. In emacs I can. I'd say using the arrow keys for navigation in text fields is a very widely accepted functionality. So isn't it vi breaking the expected behavior here?
It's not. Maybe we're talking about completely different things because I'm not following this at all, just like the other responder downthread. For decades, GUI text entry has been modeless. Larry Tessler one of the GUI's pioneers and prophets (PBUH) had a 'NO MODES' license plate and the idea remains a central theme in UI design. Vi doesn't do that. It does this:
https://en.wikipedia.org/wiki/Vim_(text_editor)#Modes
I don't mean to debate the merits of this design but in terms of 'breaking core assumptions, vi 'breaks the core assumption' of typing text into a computer. It's not, per Winnfield, the same ball park, same league or even the same sport.
- The keybindings are not the standard CUA ones. Even with Cua Mode, every page on the internet still suggests using the regular old Emacs keybindings. There's weird conflicts between some packages, especially if you use non-default keybinds like Evil. The defaults are not even ergonomic (Emacs pinkie is a thing...) or mnemonic, so there's really nothing but historical interest that makes them the way they are.
- There's no namespacing between packages. They can run right over each other and cause weird bugs. This isn't theoretical; it's what happens when you have a bunch of packages installed. Sorting out performance issues caused by the interactions between packages is very challenging.
- Lots of other defaults are super user-hostile. To get anything approaching the productivity of an editor like Sublime or VS Code, you have to spend hours installing packages, learning their unique keybindings, and sorting out conflicts.
- The base is minimal in a way (it's missing a ton of what is needed to be considered useful today) and also very bloated (it has things like mail readers and web browsers and IRC clients included). The set of default utilities needs to better match what people actually use a text editor for.
At the same time, it does do plenty of things right:
- From anywhere in the editor, you can run code---you don't need to make a new package to be able to execute a snippet of Elisp.
- Unicode works OOTB, which is impressive for a project of that age.
- Some of the "killer apps" like Magit and Org-mode are really good and have spawned their own ecosystems.
- Emacs is oftentimes the first editor to get support for super-obscure programming languages through a package.
A lot of what makes Emacs so cool and so difficult comes from the fact that it doesn't have an "extension API"---packages just run the same kind of Elisp that the editor itself is (mostly) written in.
Edit: I should also add that Elisp is an absolutely terrible programming language when compared to more modern alternatives.
Isn't it the same with VIM or other free editors?
> - There's no namespacing between packages. They can run right over each other and cause weird bugs. This isn't theoretical; it's what happens when you have a bunch of packages installed. Sorting out performance issues caused by the interactions between packages is very challenging.
without sacrificing your pro?:
> - From anywhere in the editor, you can run code---you don't need to make a new package to be able to execute a snippet of Elisp.
The fact that you can go to any package source file, modify a function and reload it on the currently running emacs instance (with C-M-x/eval-defun) kind of depends on definitions being standalone and at the top-level.
You can have namespacing in the form of prefixing identifiers with the package name. If there's name-clashing between packages, it's because they didn't follow that convention.
What more would you want out of namespacing that you can get without sacrificing or limiting that pro you mentioned?
> Edit: I should also add that Elisp is an absolutely terrible programming language when compared to more modern alternatives.
There are many reasons to hate pretty much anything. I'm not sure how you expect one to respond, if you don't give some idea of what it is that you find terrible about it. It's always pros and cons with most things.
"modern" also doesn't mean anything. Are you talking about languages that were invented recently or that are still maintained, evolving, and/or used despite being invented in "non-modern" times? Where does "modern" even start?
And the upside that everything is accessible in the scratch buffer is really worth it.
And for me, Elisp has been a kind of constant during my career. I wouldn't bet that in ten years, I'm still doing Typescript or Javascript. But if I'm still into programming computers via keyboards I will definitively use Emacs for that.
This is a commonly seen complaint, and I do not completely disagree with you. But really, if there were better options to create an editor on top of some sort of lisp-machine equivalent, why are there such few equivalent editors out there?
I would be happy to move to a new mature ecosystem that allows the sort of flexibility offered by emacs, on which tools like magit and org-mode may become popular, but I am yet to find anything in the same ballpark.
I think it's arguably the second-best language out there, losing out only to Common Lisp. Maybe third, after TCL. I certainly wouldn't want to use JavaScript, Go or Rust to extend my editor …
The worst aspect of this is keybindings. As "free-form" as Emacs is, I think it would benefit greatly from having a centralized "database" of all (custom?) keybindings. I am sick of defining my own super-cool keybinding and then either having it get overridden by a package or unknowingly overriding a package's keybindings. I kind of wish a warning would be thrown or something if you try to bind a set of keys that's already bound.
I don't know what system would be good/better, but I know I hate it as it stands today.
then you have to pick a emacs...
https://askubuntu.com/questions/297170/how-to-install-emacs-...
For some reason I now have 2 versions installed on my pop-os, (I know to pick the first one when I launch from a gui..)
I love the editor, I really like the macros, and can move around and do my editing quick.
but I've been using it 10+ years and have NO idea if I'm using it correctly.
Certain modes aren't installed depending on and its just kinda obtuse. "Space emacs"? How do install a plug-in again.. where is my .emacs config file? is it init.el? ...
sigh..
A more interesting answer is bash - I will often check the man page before I Google.
He sounds like some random person spewing random subjective opinions about things, rather than the original author of GNU Emacs making an honest effort to provide leadership and guidance that means something (anything) to anyone other than himself. He sounds helpless and oblivious to everything and everyone except his own personal proclivities, which is the opposite of leadership and the opposite of an experienced person providing valuable guidance to the community. Like he's not even making a token effort to do those things, and to say he's metaphorically lifting a finger here to provide leadership and guidance would be very generous.
This is akin to Linus rejecting a driver because he doesn't own the hardware, or because he doesn't like the colors of logo of the company that makes it. It really doesn't get more incurious and intellectually/emotionally immature than that.
This is in 2020, after a couple decades of Emacs being one of the only actual software projects he involves himself in anymore. To be clear, I've had a really low opinion of RMS for going on 20 years now (after a few years in college where I thought he was cool because I didn't know any better and people seemed to revere him because they thought everyone else revered him). But reading these mailing list exchanges are still kind of shocking to me. It's really hard to believe that anyone on the GNU mailing lists pay any attention to him at all, or values his opinion on anything. For those that do, surely that's nothing more than a cult of personality, it just seems as plain as day to me. This is exactly the sort of thing that drives people away from GNU and the FSF, and it sucks because they could be so much more impactful and meaningful and helpful and positive and constructive otherwise.
Sometimes I think if more people had simply stopped making excuses for RMS like 20 years ago, we might currently be living in some sort of GNU utopia dreamworld where everyone everywhere uses Emacs for everything, and GCC is the preeminent compiler suite, etc. etc. etc. It's quite a high cost for people to pay, when the only thing they get in return for keeping this guy around is helping a damaged narcissist continue to feel good about himself and continue alienating everyone else, just like he's been doing for decades. He absolutely got GNU and the FSF off the ground and helped create a large community that has produced tons of great software, but in the past 25 years it seems like all of his efforts have been counterproductive to his own goals.
He seems out of touch even with modern emacs packages. He doesn't use any of them, doesn't even know what they do, I guess he uses the same config since the 90s, doesn't try new packages, he's more interested in preaching the GNU message.
And he believes the right thing for the core Emacs-developers to do is to spend their time trying get everyone in MELPA (a modern package repo, with a modern GUI, based on modern tools and workflows) to instead move their packages to ELPA, with all the change in tools, modernism’s and workflows that entails.
He seriously believes this is important because MELPA isn’t GNU, and that’s all he cares about. It’s not enough to be open-source and free. You must be GNU, or it doesn’t matter.
He may add things of value still, but I refuse to believe it’s not overshadowed by all the backwardisms he constantly tries to impose on the core developers actually doing the dirty work.
It's not like he's been doing anything else for the last 30 years.
Following the discussion on Emacs-devel it does seem quite the opposite: you often see people with progressive ideas moderating themselves to not get too out of line with RMS. People (unconsciously?) try beating around the bush, to avoid touching GNU dogma, rather than going straight to the point, communicating efficiently.
While I really appreciate what FSF and GNU has done for computing, I believe the limitations Emacs-developers are putting on themselves by religiously denying to integrate with anything non-GPL (another Stallmanism) is going to hurt Emacs long-term, rather than benefitting GPLed software.
I guess time will tell.
Iirc GTK was born out Gnome, and Gnome was born as a FSF-project.
[0]: https://gitlab.gnome.org/GNOME/gtk/-/tree/master#licensing-t...
If that were the case, then why was GTK not updated to GPL or LGPLv3 when the FSF came up with that group of licenses?
When I looked it up, I found that QT is available under LGPLv3[1], so unless there is already plans to ensure that a GPLv4 is not license compatible with LGPLv3, I don't buy it.
1. https://doc.qt.io/qt-5/lgpl.html
Software-as-a-service under GPLv3 isn't required to provide source code to remote users (AGPL acommplishes exactly nothing in this regard), so there definitely is such a need, but I don't know if RMS is actually working on that.
However, the problem I was actually thinking of ("exactly nothing"), was that last time I looked into it, the consensus appeared to be that you could copy code between a AGPL project and a GPL one, which obviously makes the AGPL useless. But, on checking, I can't actually find a citation for this, and the licence text doesn't seem to support that interpretation.
So I have to retract my previous statement and amend it to: the AGPL does very little to help with SaaS attacks on open source software, primarily because almost noone uses it, and because the FSF continues to recommend the known-broken non-affero GPL as its default copyleft licence.
In fact instead of being in either the vi or emacs camp, I use both. I also use Eclipse.
Each of them for the task at hand.
maybe when internet users stop treating their text editor choice as their identity people might start using them more?
――――――
¹ — https://rust-analyzer.github.io/blog/2020/04/20/first-releas...
² — https://magit.vc/
https://www.youtube.com/watch?v=rzQEIRRJ2T0
My skills with git have gotten better after using magit, too, because it brings the power of git to the surface. It's a really fantastic git porcelain and the fact that it is deeply integrated into Emacs just makes it absolutely second to none.
Magit is easily one of my favorite pieces of software and I will leap at the chance to sing its praises.
Meanwhile new generations of people have different tools and aren't held onto these past ones because they didn't start with it (and they weren't coding in the 80s). The world of computing generally has moved on with new ideas, new experiences, and new form factors. So their new tooling has won them over, and outcompeted a dying generation.
This is a good thing! It's called progress. Unless Emacs is willing to have fresh blood decide a new direction for it, it will be relegated to history. If Apple held onto its Apple II vision, we wouldn't have the iPhone today. Either you are willing to fundamentally change with the times, or you aren't. Emacs has shown they aren't, and they've had over three decades to do so. Fortunately others will in their place!
Think of shops that sell novelty items. Newness at an object level looks like novelty items. What is the quality of novelty items? How long do novelty items last?
I surely would want to go back to the pre-corona days.
(https://en.wikipedia.org/wiki/Lindy_Effect)
Emacs has/had the option of changing with the times. They’ve opted out of that. So most newcomers will opt out of emacs, and thus it’ll slowly die out.
ultimately, emacs improved because of them.
While your first statement is true, taking the second one for granted is dangerous and may lead to the exact opposite.
Every long-term FOSS project needs to continuously ensure it maintains a healthy level of contributors, or it will die.
Unfortunately when I tried Spacemacs (coming from Emacs) I kept bumping on rough edges with vim command emulation which ended up with me switching directly to the real vim. It's been about a year now and while I still think I was right to finally make the switch to modal editing, vim feels like a clunky and hacky environment compared to the power of Emacs.
I mean good for them having that option, but what’s in that thing for me?
And I’ll also have to learn all the things it does differently. All in all, sounds like a net negative to me.
Again: what’s in it for me supporting this alternate Emacs universe?
Also, The vim emulation has gotten much better due to evil-collection[1]. You might want to give Spacemacs or doom-emacs[2] another try.
[1]https://github.com/emacs-evil/evil-collection [2]https://github.com/hlissner/doom-emacs
As far as spacemacs goes it seems neat. I tried it once but it was too confusing and I've been using emacs for so long now that it's very finely tuned to what I need it to do.
As a very long-time Vim user, I prefer that my editing commands be predictable since I type them with muscle memory (faster than ordinary conscious thought). Having them vary from file to file based on file type (the Emacs way) throws me off completely and makes the editor feel untrustworthy, like a horse that's liable to kick or throw its rider. Vim feels like a complete set of high quality, manual woodworking tools.
Clearly my Emacs origins show here, because not having simple built-in motions to select "a function" or "a class" feels like a big limitation to me. I actually have a bunch of ad-hoc bindings for that. I also seldom use paragraph motion while coding simply because it doesn't really make a lot of sense to me. I think about code in lines or blocks, not paragraphs that is a rather weird concept when it comes to code. The fact that you can't easily add new motions to vim is a big limitation for me.
>Vim feels like a complete set of high quality, manual woodworking tools.
They're mostly reliable and predictable, I agree with that. High quality I'm not sure. The fact that the undo tree is effectively unusable without 3rd party plugin is weird. Tabs are at the same time over-engineered and under-featured. Nobody seems to really knows what they're for or how to use them (just make a quick search online for "vim tabs").
They're like Emacs frames except that you can't actually use them like a separate frame on a different screen. And you can't have them use a different working directories easily so they're useless to open two projects side-by-side. Some people coming from editors that open files in individual tab (an anti-pattern IMO, but that's a different discussion) expect them to work that way, but it turns out that they can't really do that either. Why even bother?
You also need plugins to do very basic coding stuff like run "make" in the background without being locked out of editing. Which wouldn't be too bad if Vim's internal API made it easy to make Vim plugins work seamlessly like native code, but in practice all the plugins have tested needed to be super intrusive to offer basic functionality (like remapping literally half the keyboard to slightly tweak the kill/yank behavior) and it ends up breaking left and right in weird and unexpected ways.
The visual feedback for commands is atrocious. Spacemacs' genius is that when you start typing commands it shows you what you can press next and what it does. You effectively navigate the bindings like menus, and you have this positive feedback loop where you memorize the bindings by using them. Sometimes I start typing a command in vim and I think I made a typo but I can't know because I have zero feedback on the current state of vim. Emacs almost always tells you what it's waiting for in the mode-line.
Why does ":bdelete" also kill the window it's in, except when there's only one window left? Since elsewhere there's no 1:1 relation between windows and buffers, you'd expect to get the next buffer in the stack (that's what Emacs does in this situation, and that's what Vim does when you have one window left). Window and buffer handling is hard but Emacs is vastly more configurable and works better out of the box in my experience.
I also often get performance issues that I don't remember ever getting in Emacs which is fairly ironic given that Vim is supposed to be the "lean" one.
I think so. The Emacs philosophy is essentially to treat the editor like a highly-customizable IDE. I use Vim only because I want a Vi that has a few quality-of-life tweaks here and there (the undo tree works fine for me without any plugins, I just use g- and g+). I don't use the vast majority of what was added. The core of what I want was created by Bill Joy back in the 70s.
I want a text editor that works the same whether I'm editing a C source code file or a text file that happens to have some C pasted into it or a configuration file or a file that looks superficially like C but happens to be a different language. I'm not interested in an IDE. I would prefer that most of those language-specific tools be separate programs that I can invoke by shelling out.
Performance issues in Vim are usually caused by various autocompletion engines, none of which I use. I like Vim's built-in completion which is very simple and predictable (fitting the theme), invoked using C-x in insert mode.
i tried spacemacs and it was like trying to fit a square peg on a round hole -- it just doesn't work properly.
You can run emacs --daemon at login and run either emacsclient to start a new window connected to an existing instance. In my measurements starting vim in a new xterm takes about 250 ms. Starting a new gui emacslient requires only 500 ms. Perhaps numerously running a new default emacs instance with emacs -Q is actually faster at 400ms.
I think it comes down to performance, especially startup time. Emacs developers have never cared much about it, and I think that's connected to its reputation for "bloat."
The death knell rang when Linux distros stopped distributing Emacs by default; Emacs isn't installed by default on Ubuntu or Fedora, say nothing of macOS or the Windows Subsystem for Linux.
If I were working on Emacs, my #1 goal would be to beat Vim on startup time--to get the first page of text to show up faster than Vim--and my #2 goal would be to convince the major distros to include Emacs by default.
Sadly, I don't think any of this will happen. Stallman is too far out of touch, not just with newbies, but even with active users of Emacs. As the article points out, he's never even used Org mode! https://lwn.net/ml/emacs-devel/E1jR5ss-0001xM-L9@fencepost.g...
EDIT: I know you can do some non-default techniques to make Emacs start faster. But that won't get Emacs to be installed by default on popular distros. Installing more plugins won't make Emacs the quickest and easiest way to edit a file.
https://www.gnu.org/software/emacs/manual/html_node/emacs/Em...
https://www.emacswiki.org/emacs/EmacsAsDaemon
https://www.reddit.com/r/emacs/comments/f3ed3r/how_is_doom_e...
edit: am emacs (and nvi) user. just chiming in on .1ms vs 1ms startup time arguments as a basis for anything important
I used to use "jed" as a close to Emacs, light text editor to use for a quick edit from the shell. Nowadays I aliased jed to "emacs -nw -Q" (-nw: text mode, -Q: skip all configs), which subjectively starts instantaneously. And even a bare Emacs skipping the system an my configurations is very powerful. It also supports millions of colors with Konsole, so it's nice when reading code.
Rather than worrying about startup times, I'd have them work on including a lean set of quality of life extensions by default, like ido.
2) You already use Emacs. What would it take to get a new user to use it? It would have to be installed by default, and be the quickest and easiest way to edit a file. That means startup performance.
Or the server/client setup could just be the default and the server starts at system boot.
By default it uses a global session context, but for example I configure mine to save the session locally in the directory where emacs is started. Then I can have several projects in parallel, and when I start emacs in the project top level directory it restores the session for this specific project. I also make the session saving file name machine specific, and ignored by unison for file synchronization. So the layout is specific for each machines with possible different screen setup leading to different window organizations. Just an example, you can tune it to fit your own needs --- that's the whole point of Emacs to me.
Not only does the desktop session remember and re-open the files, but it also remembers what frames you had open, what position on the screen and which screen the windows are on.
It is a huge convenience.
> my #1 goal would be to beat Vim on startup time
You have some weird priorities
> Stallman is too far out of touch ... but even with active users of Emacs
FUD! He monitors the emacs bugs list. Also I just 2 days ago got a response from him personally regarding emacs. Note: personally.
No credibility for you, sunshine.
To your second, rather obnoxious point: when they said 'out of touch', they didn't mean 'hasn't been in communication'. They meant he doesn't understand the attitudes/motivations/requirements of the community.
IME the emacs devs are very considerate of requests so I have to disagree.
Edit: by contrast have you ever tried reporting a bug to microsoft? Something non-trivial. I have and it was just a wall of indifference.
You were willing to apologize to well-known contributors, but everyone else can stuff it?
Other people need to improve things. But this is not going to happen. An alternative to doing something is to dismiss other people's work. That's what this guy did. 'Emacs is too slow' - emacs startup time doesn't bother me, even if it did it would be down in the noise amongst other emacs irritations (or other software, heck, the amount of time I've wasted on Git...)
He dissed emacs for no good reason, and dissed stallman who I really do respect (because RMS actually did something).
I've seen a lot of this kind of destructive behaviour and I'm so tired of it. I should just leave HN if I can't contribute properly.
Edit. If I post stuff like "x != y" I will say why, with timing, or clarify with In My Experience" or something. "emacs is slower" doesn't tell me by how much or discuss if startup time even matters, so it is a useless criticism; I can't act on it. It doesn't even feel like a good-faith comment.
Interesting. How did you get it to store the list of previously opened files?
> If I were working on Emacs, my #1 goal would be to beat Vim on startup time-
With emacsclient, I don't think this is relevant. Concern about startup time certainly wasn't part of the reason why I put off switching for so long.
Startup performance isn't about persuading fence sitters. It's about becoming the default, the option people pick without even knowing why they picked it.
Eight Megs And Constantly Swapping. ;-)
* Eventually Mallocs All Computer Storage
* Emacs Makes A Computer Slow
Emacs key combinations are weird. Discoverability is low. Even Vim will now tell you how to quit if you Ctrl-C it.
Meanwhile I have opened Emacs and I'm trying to quit it (spoiler: Ctrl-x Ctrl-c). Some things are actually interesting and it tries to help at first but then it goes back quickly into emacs-babble that doesn't help much.
The case for vim is simple: a quick editing of a file when you might not have a window manager up or on a terminal.
I don't see many reasons to learn Emacs when VSC, Atom or other editors exist.
That, and the power of its keybindings.
> I don't see many reasons to learn Emacs when VSC, Atom or other editors exist.
I think evil-mode, org-mode, dired, and magit, make a pretty compelling case for Emacs to fit into many programmer's workflows, even if it doesn't displace their code editor or IDE outright.
Though even setting up just those packages requires quite a bit of configuration.
Counter-point: I think emacs makes much more sense. If you start it, you can navigate a file by clicking in places. It is a GUI application, whereas I think vim is just a terminal program by default?
Emacs has a little built in tutorial (Ctrl+h t) and is quite discoverable (type Ctrl+h ? and it shows you a lot of commands you can use to find out about what functions a chord invokes or how to invoke a function with a key cord). With helm you just type a part of a function and it gives you a list of suggestions.
Within programming languages I think auto-completion is a must-have for discoverability. Otherwise I have to constantly look up stuff in the documentation. And for that company-mode is really nice, I don't know about the vim side of it but I think something like that goes against the philosophy of vim as I understand it?
To me, modal editing didn't make much sense in the beginning and for emacs the learning curve seemed less steep, so that's what I went with in the end. But clearly it must be good somehow, because so many people use and love vim! It's just not for me I guess.
(There are gui versions of VIM as well but it feels weird)
Also there is documentaion for literally all the key bindings and all the functions. You can access the code for all the functions. Emacs is much more user friendly than Vim.
this reputation by the way was 'earned' when entire computers had less memory than a typical emacs or vscode instance, and similarly, emacs likely currently uses less RAM than vscode due to afformentioned electron. Also: vi vs emacs 'bloat' wars were in reference to actual vi, not vim, which basically has the same non-core functionality as emacs (e.g. GUI widgets, editor-hosted scripting language) that was the basis for the original 'bloat' argument.
this is not very coherent.
But, short of that, Emacs can't beat VS Code. Emacs could beat Vim, but only by being so fast and small that it gets installed by default on Linux distros (and macOS and WSL).
But that'll never happen, because Emacs folks prioritize features over performance. (If they cared that much about performance, they wouldn't be Emacs users!)
Thinking of switching to gccemacs for the native elisp goodness. But way too much yak shaving has been done already. I just disabled lsp-ui and lsp-company and all good.
Emacs is not vim. Emacs is not designed to be a program you open for every file. Emacs is and IDE. You open it every time your computer starts, and then you go to Emacs and find files from there. Occasionally, you'll have a file and want to look at it, and then you'll use client mode to have it open in a new buffer in your already opened Emacs window/terminal.
I do agree that this is not the way anyone starting out would use a text editor. But if this way of using it is not comfortable to you, you'll be fighting so much of emacs that you really will have a miserable experience, regardless of startup time.
Just to hammer the point home, normally if I connect to a Linux system and want to edit a config file, I would do the following: either `sudo vim /etc/hosts` or `emacs` and `C-x C-f /sudo::/etc/hosts`. I don't think too many people would run `sudo emacs /etc/hosts`.
And that's why Vim is installed by default on Linux distros (and macOS and WSL) and Emacs isn't. And that's partly why people learn Vim before they learn Emacs.
We probably also disagree on what exactly it means to learn Vim before learning Emacs. I've been using Vim as a console editor far before I knew Emacs existed, but I have no idea how to use Vim for anything more than basic editing. Choosing an editor to learn as your development environment (which is what I would consider 'learning Emacs/vim/etc' actually means) is unlikely to be a decision you take based on system defaults. You are far more likely to learn the editor/IDE that your mentors use, whether that is Vim or Emacs or, as was my case originally, Borland Turbo C. Alternatively, when you are experienced enough to make a conscious choice of editor to invest in learning and customizing, your criteria will be more varied, but still likely not depend that much on system defaults.
The Vim out-of-the-box experience is not exactly great (crucial features like vim-surround have to be installed as a plugin, for instance, in the terminal version there's a lot of delay on some commands, etc). But while learning the unfamiliar keybindings initially takes effort, the huge speed advantage of modal editing becomes apparent after just a few days of sticking with it, and it becomes second nature surprisingly fast, to the point where you just stop considering editors which don't have decent Vim emulation. So while I wouldn't exactly describe Vim as accessible, it gets its core idea across fairly quickly.
By comparison (and also in absolute terms), the Emacs out-of-the-box experience is horribly bad, it seems to make no effort to wow its first time users. It stubbornly sticks to a keybindings scheme that is unfamiliar to a modern audience and which, crucially, unlike Vim's keybindings offers no substantial productivity boost. All the documentation even still calls the Alt key "Meta". So you spend multiple days getting used to Emacs' keybindings scheme, only to end up roughly where you started (not much faster than before). At this point it's easy to start feeling like learning Emacs is not worth it: you've just spent days learning without your productivity increasing, and you just have to take people's word for it that, no, really, it'll get better. The main selling point of Emacs is its extendability. But this point is lost on users who aren't already convinced that they love and want to use your editor. You have to provide a good out-of-the-box experience still.
Not everyone is willing to invest this time and therefore IMO it won't be a very popular environment for most users. I don't blame them, everyone's needs and priorities in life are different.
Or you could start with a popular .emacs.d (I use Doom Emacs), tweak a few things, and tell yourself "I don't need to modify yet another key binding" a hundred times.