GNU Emacs: Competing With Other Editors—Should It?

Today while browsing the Emacs Reddit I came across this interesting thread. The sensationlist title contains the following quote from co-maintainer Stefan Monnier:

We’re not in the business of competing.

He is referring to competing with other editors and IDEs. Today I want to frame his comment in the proper context and discuss whether GNU Emacs should compete with the likes of Visual Studio and Eclipse.

The Context

Stefen’s comments come from a thread discussing the policy for packages in ELPA, the official Emacs package repository. In the emacs-24 branch of the official repository, the Python mode has going through various non-bug–fix changes. Some people believe this should not happen. Changes to language-specific modes should adhere to the same feature freeze as everything else. Other people believe that changes to such modes should always be welcome, assuming that don’t break anything. One argument for this is that it helps Emacs stay up to do with editors that pump out new features, and this would help Emacs keep up.

And here came the, “We’re not in the business of competing comment.”

The Benefits of Not Competing

GNU Emacs has long done its own thing. Any long-time user will tell you that. This attitude allows the Emacs developers to focus on what interests them without being beholden to the trends and practices of editors such as Visual Studio. Granted—a lot of Emacs Lisp developers will simply ‘steal’ those features be re-writing them in Emacs Lisp, but that’s beside my point.

Decades of this attitude has created an atmosphere around Emacs where newcomers are expected to conform to the standards of Emacs, or to move on to something else. “Why isn’t Control+S ‘save’ instead of starting a search?” I’ve seen these questions a lot. Emacs fans tend to trot out three responses:

  1. You can bind the keys to whatever you want. (Non-obvious to most on how to do that.)

  2. Emacs was that way long before Control+S because the standard for save. (Clinging to the past in an effort to avoid change.)

  3. You’ll get used to it soon enough. (The weakest of all rebuttals.)

It’s worth mentioning CUA Mode helps these issues. But then you have the long-term users who seem to view CUA Mode with the same disdain that the Brazilian national football teams has when it comes to guarding their goal against Germans.

Long Term Objectives

I saw the following quote in the discussion linked above. It in no way reflects the Free Software Foundation. That said, this is not the first time I’ve seen this?

They do not want to succeed in any of these criteria. Users, developers, and donations are nice to have, but simply not a priority of GNU and the FSF.

The only thing they really want to succeed at is freedom, and by their measures Emacs already succeeded in this aspect, being a free software project under a strong copyleft license, owned by a non-profit foundation.

And that freedom does not fade or decrease if Emacs fail to attract users, developers or donations. The license ensures that Emacs is going to remain free as long as our legal system persists, even if no one was left using or developing it.

The Hell…? As another poster succintly put it, “Freedom without people, that’s an interesting goal.”

The Free Software Foundation (FSF) cannot have an attitude like this. They must realize that they compete with other editors whether they want to or not. Many programmers seem to make their choice in editors after trying each for about fifteen to thirty minutes in my experience. Emacs should do whatever it can to rope in new users within that time frame. It’s esoteric behavior that made sense decades ago no longer stands against todays standards.

Now then, the power to customize Emacs is second-to-none. But there is no reason to expect a new user approach Emacs to even realize that. Even worse, some users feel like such new users are hurting the community. They would rather have Emacs as an inclusive club for people who have invested the effort in its arcane arts.

Conclusion

How to change this community culture? I will write my thoughts in the future. But I admit to having no simple answers. If you have any thoughts, ideas, or disagreements then please leave them in the comments.

Advertisements

22 thoughts on “GNU Emacs: Competing With Other Editors—Should It?

  1. I don’t agree with the general sentiment in this article. The “common responses” are in fact quite valid, and the disdaining comments in parentheses doesn’t make them less so.

    There is nothing wrong with making is easier to get into the tool for new users, but it should not be done at the expense of the things that makes it good. The C-s (isearch-forward) is a good example. It’s in a prime location on the keyboard and using that for a feature that is used very rarely (saving) doesn’t make much sense, regardless of what Microsoft Windows does.

    By the way. Guess why CUA mode was included in Emacs in first place? For the purpose of making transition easier for users coming from (mostly) Windows editors. Couple that with the popular “Emacs starter kits” that are out there, and I don’t really see what the problem is.

    1. “a feature that is used very rarely (saving)”

      I find this a peculiar claim. I would have to actually measure it, but I may save more often than I search. Either way, both are very common actions in my workflow. Although I like the paradigm that I see in Windows editors where Ctrl+S is save and Ctrl+F is find, both of which are on left hand home row allowing for easy one-hand chords while the right hand may be working the mouse. What is the keyboard shortcut for saving in Emacs, ooc?

  2. Having worked in the software industry for 15 years, obeying feature freeze is pretty critical if you are actually trying to get a release out the door. Given that Emacs users can very easily pick up newer versions of packages outside the officially released versions, this looks like a storm in a teacup.

    Essentially, 99.5% of users will be fine with what ever is officially packaged at release point. For the 0.5% who want a bleeding edge feature, they can go grab it right now and use it.

    1. …beying feature freeze is pretty critical if you are actually trying to get a release out the door..

      This is a great point of software-development and I could not agree more. However, in the case of Emacs, should the latest Python Major Mode be beholden to feature-freezes? Personally I sai ‘no’ because it provides benefits that denelopments can benefit from right now instead of waiting. Assuming there’s no bugs; as the maintainer of PHP Mode, I have screwed tha up before.

      Essentially, 99.5% of users will be fine with what ever is officially packaged at release point. For the 0.5% who want a bleeding edge feature, they can go grab it right now and use it.

      In my experience package repositories are not managed by any form of release point, e.g. Git tags, but instead are uploaded whenever the developer pushes a new version. I believe your numbers are more accurately 0.5 a

  3. I think there’s a key point here.

    Commercial software exists to make money for the company. That means the goal is to sell software. From that, we often make the correlation between number of users and value/quality of software.

    That’s not true, though. More users does not mean better. Once you give up that idea, the statement that emacs is “not in the business of competing” makes perfect sense.

    A software project, like emacs, that is created by and updated by volunteers needs to have a large enough community to successfully maintain it. That’s it. Too small, and it fades away, too large, and it loses focus.

    The goal isn’t to compete; the goal is to write great software for our own use. It’s a nice side effect that creating good software for our own use helps other people, too.

  4. Commercial software exists to make money for the company. That means the goal is to sell software. From that, we often make the correlation between number of users and value/quality of software.

    I disagree that the price of a product correlates to its quality, however I do think you’re correct in saying that sinc a lot of people see that correlation, whether it has any true value or not.

    More users does not mean better.

    For a community I believe that more users does mean better software. I would rather have 100,000 Emacs Lisp programmers working on packages than 1,000. (I admit that I’m making these numbers up, as I have no idea how many work on ELisp.)

    A software project, like emacs, that is created by and updated by volunteers needs to have a large enough community to successfully maintain it. That’s it. Too small, and it fades away, too large, and it loses focus.

    I could not agree more.

    The goal isn’t to compete; the goal is to write great software for our own use.

    Finally, though, I must disagree once more. i don’t want to sound like I’m attacking your post because it’s well-written and you raise good points. But Emacs must ‘compete’ in the sense that if it remains stagnant with regard to the features of other editors and IDEs then it will fade into obscurity. The fact that it is free is not a “selling point.” When a new user tries Emacs he’s looking for stuff like syntax highlighting, search-and-replace, etc., the freedom to do as he wishes with the source code is of no consequence. So Emacs has to thrive on promoting features through competition, not resting on the laurels of the FSF’s philosophy.

    Thanks for the comment.

    1. “the freedom to do as he wishes with the source code is of no consequence.”

      I think this is a great point. While it is nice to have a customizable editor, ease of getting something working needs to be considered. If I have to trawl through source code written by several people to implement several features I want, then compile and test it, I’d quickly ignore said tool for one that already has that work done for me. Otherwise, we would just have one open source project with an empty main called “Utopia” that is the best editor/OS/browser/game/anything because you can make it do whatever you want by editing the source :).

      1. Obviously when discussing GNU software and the FSF, the freedom to do as one wishes with the source code (provided that freedom is preserved) is of primary import.

      2. @Anonymous

        Obviously when discussing GNU software and the FSF, the freedom to do as one wishes with the source code (provided that freedom is preserved) is of primary import.

        I’ve been using GNU software since 1993 and have very rarely felt compelled to change the source code for anything. I am very happy that the option is there, but for most users I suspect it doesn’t matter. I agree it is of primary importance. But when it comes to helping Emacs stand out from its peers, it’s irrelevant. How many people honestly modify the source code for GNU Emacs and use it for that reason? I would safely guess not many.

      3. Yes, that’s beyond any doubt. Proportionally speaking, very few users will ever directly modify any source code themselves.

        (That said, personally I would argue that most of the users of GNU Emacs do in fact use it for that reason — whether they’re aware of it or not — as a great many of the features that they love simply wouldn’t exist were it not Free Software — but I realise that’s a step removed from what you were referring to.)

        My point was simply that it’s more or less impossible to discuss what the authors of GNU software should (or should not) be doing, without taking into account that freedom simply is the most important thing to the FSF.

        The person who wrote “Freedom without people, that’s an interesting goal.” was being rather disingenuous, I IMO. The goal is Freedom; not “Freedom without people”. Just Freedom. (And there will always be people who want that.)

        Fortunately, I don’t think there’s any conflict between freedom and features; and in fact Emacs has adopted many features in recent years which are intended to make life easier for users coming from other editors. The likes of shift-selection, and various other region-related functionality spring to mind.

  5. That said, personally I would argue that most of the users of GNU Emacs do in fact use it for that reason — whether they’re aware of it or not — as a great many of the features that they love simply wouldn’t exist were it not Free Software…

    I agree with your sentiment. However, I believe even more people use GNU Emacs because it’s really just a flexible Lisp environment with an editor on top, and once you get used to that it’s incredibly poweful.

    My point was simply that it’s more or less impossible to discuss what the authors of GNU software should (or should not) be doing, without taking into account that freedom simply is the most important thing to the FSF.

    That’s a fair point. So let me ask this then: is the promotion and increased adoption of GNU Emacs important to the values of the FSF? To put it another way, does it help further their ideals for Emacs to become more wide-spread than, say, Sublime Text, Textmate, XCode, et cetera?

    The rest of your good points I agree with.

  6. The comment you quoted would indicate that no, increased adoption of GNU Emacs (and presumably other FSF software) doesn’t appear to be seen as furthering their ideals.

    You simply don’t remove yourself from competition by declaring that you’re not competing. Your potential users do not care if you declare non-competition, they’re still going to look at Sublime Text, vi/vim and all the other editors out there. Programmers who care about their craft – yeah, we’re a vocal minority – do care about their tools and the tool you spend most of your time in is your editor. People like that are unlikely to change horses or editors mid-stream.

    Freedom without people is an interesting goal, but if all that gets you is a handful of people who get to bask in their air of moral superiority, you end up in “neat idea” territory. To be part of a functioning (software) ecosystem, a piece of software will have to that users. GNU Emacs does have the advantage of having lots of code written for it in the past so the ecosystem will be sustainable for a while, but over time you would want an expanding user base if the project isn’t going to become stagnant.

  7. Like all software products, proprietary or free, Stefan is in the business of making stable releases. Thank goodness for that. In the case of python.el it seems that there were significant changes to the codebase beyond just regression fixes. This included lisp bindings that python.el provided. So any user that had customizations to python.el might not see them working anymore. That’s bad etiquette when maintaining an Emacs mode.

    1. Thanks Aaron. I was under the incorrect impression that the proposed changes for Python Mode did not cause any regressions. Since they do, however, I agree that it would be bad to release the mode until those are sorted out.

      (Says the guy who’s broken PHP Mode over and over…)

  8. Hi, I can’t agree more about historic reasons making newcomers run away. CUA mode is a partial solution, ErgoEmacs has some interesting answers, too.

    Nu-mode is a similar global minor mode to adopt modern keys. In order to provide both modern keys and a reasonably large set of functions, if relies on key sequences + prompts to advertise what is available. So, control+f will find, but one will be able to isearch regexp, find a string, ace-jump… Control+o will open, but either a file, a buffer, a bookmark, the org agenda… And so on.

  9. As a long term Emacs user, I’m quite happy to keep the editor as one that isn’t entirely friendly to new users. There are lots of editors out there suited to beginners who want to be spoon fed. I think there’s a real benefit to being a part of a community where everyone is the type of person that has persevered long enough with Emacs to become productive. I think making Emacs really easy to use from the first moment would lead to a kind of “eternal September” type event.

    1. First, thanks for the comment.

      Second, you’re making me feel old by virtue of the fact I remember eternal September. Thanks, heh.

      I apologize if I’m putting words in your mouth, but you make Emacs sound like military basic training that have to endure before they “graduate” to the rank of ‘true user’. With all of its customizability, can Emacs not be one of those editors for beginners and a powerful tool for those of us who invest way too much time in it? (Or I do anyway.) Re. the eternal September comparison, I think the task of learning Emacs Lisp would prevent the ecosystem from being flooded with half-assed packages, but that’s only my gut feeling.

      1. Certainly for me, I was a competent productive programmer before I started using Emacs and then I took a huge productivity hit for a long time before I got back up to my previous level (this was quite a while ago. Projects like ESK make it a lot easier to get started now). (God bless Steve Yegge and all who sail in him for his convincing argument that it would be worth it).

        I think that hump in the learning curve leads to an interesting eco-system of craftsman who are willing to put the work into something difficult in order to become better in the long term. Of all the clubs I belong to, Emacs is my favourite.

        There’s plenty of editors out there that are easy to learn. Let’s leave a couple of hard to learn ones out there just to keep the interesting communities around them. (We wouldn’t want a mono-culture of easy to learn editors, would we?)

      2. Learning Emacs also hurt my productivity for a decent amount of time. I spent years going back and forth actually. I agree with you that the learning curve and the investment necessary to learn Emacs Lisp helps fuel the quality packages out there. I still think we could make it a little easier, but I can see your point of view, so I can only respectfully disagree that we need some “hard to learn” editors. I’m not suggesting we dumb-down Elisp itself, but maybe the community would benefit from increased adoption if we did something like enable CUA Mode by default, because I can’t count the number of “What the fuck?”‘s I have heard after explaining C-w, M-w, C-x C-f, and so on.

        But as long as people aren’t using Vim, I’m happy.

        (Heh nah, Vim’s great too.)

Add Your Thoughts

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s