11

Making Emacs Popular Again

 3 years ago
source link: https://lwn.net/SubscriberLink/819452/1480c3a59d3d9093/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Welcome to LWN.net

The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider accepting the trial offer on the right. Thank you for visiting LWN.net!

Free trial subscription

Try LWN for free for 1 month: no payment or credit card required. Activate your trial subscription now and see why thousands of readers subscribe to LWN.net.

By Jake Edge

May 6, 2020

The Emacs editor predates Linux, and was once far more popular, but it has fallen into relative obscurity over the years. In a mega-thread on the emacs-devel mailing list, participants discussed various ideas for making Emacs more "attractive", in both aesthetic and in "appealing to more users" senses of that term. Any improvements to Emacs in that regard have numerous hurdles to overcome, however. There are technical questions and, naturally, licensing considerations, but there is also the philosophical question of what it is, exactly, that stops the venerable text editor from being more popular.

So square

The discussion started withpost from "ndame" asking why Emacs is " so square "; the appearance of things like buttons could be improved with rounded corners, they said. Richard Stallman, one of the original authors of Emacs, seemed somewhat dismissive in hisreply: " Perhaps we should implement a mode that puts cosmetics on Emacs so it will appeal to those who judge by the surface of things. " But Stefan Kangasthought there was more to it than that:

I also don't know that it's helpful to assume that the rest of the world will take the enlightened stance. For example, I've always assumed that many people use Sublime Text not due to any serious feature comparison with Emacs, but because they like its "sleek look".

He wondered if there was " any reason not to improve the default look ". Stallmansaid that there are some technical barriers in finding someone interested in and capable of doing the work needed, but there is an overarching problem that needs to be addressed first:

The code to interface Emacs to X-based GUIs needs rewriting by an expert, and has needed it for decades. Until it gets that rewrite, changes in it are likely to break something.

Stallman did agree that the graphical design could improve usability, " but I have a feeling that the changes that would help are deeper issues than the shape of corners ". The GUI interface only matters if Emacs users are leaving those features (e.g. the menu bar and tool bar) enabled, Eli Zaretskiisaid, but much of the advice out there on configuring Emacs suggests disabling those things.

It is hard to be enthusiastic about making these features more modern when the community seems to be divided on whether they should at all be present. IMO, we should first get our act together and decide whether these features are important, and then speak up according to those decisions when we see advice to the contrary.

Beyond that, though, there are bigger problems with Emacs as a whole, Joseph Garvinsaid. The Emacs user interface " doesn't look or behave like any other application ", the keyboard shortcuts are different than other programs, and the terminology used in the Emacs world does not match with what users expect:

You are basically making a commitment to being or becoming a power user. I certainly would not have put up with it if I didn't think it was going to save me a lot of time as a software developer (and it does, everyday). I doubt anyone invests the mental effort to deal with learning emacs nowadays unless this is their goal. If you just want to do "casual" text editing emacs is a very weird choice in 2020.

But "modernizing" Emacs (however defined) is likely to be a waste of the project's time, since its look is not what's holding it back, Ahmed Khanzadasaid. For example: " Terminal-based Vim is not like a modern application, yet is more popular than Emacs. " The appeal of an editor that can be extended using the Lisp language is somewhat limited, he said. Spending a bunch of time and energy to give it a modern look would not change that and, by the time the work was done, the definition of "modern" will have changed again.

Popularity

Kangaswondered about the assertion of Vim's popularity; Khanzadapointed to a 2019 survey that showed Vim with a substantial lead over Emacs (20% to 3% is what he reported, though it shows 25% to 4% as of this writing). That survey showed that Visual Studio Code (VSC) is the clear winner, however, with 50+% of respondents using that tool. You could perhaps quibble with the survey's methodology, but the broad-brush numbers do not seem wildly out of line.

That set off some discussion of why users prefer the experience with VSC. " We need to figure out why VSC is so popular, and then fill in the areas that Emacs is missing ", Po Lusaid. Bob Newellthought that " the goal of making Emacs more accessible and more appealing is laudable and ambitious "; it is something that the project could accomplish, he said. He is worried, though, that today's software is aimed at "instant gratification" rather than long-term usability—and power.

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. I certainly draw the line at saying Emacs is for everyone. I'm not saying it's only for some sort of snooty "elite" but I am saying that it's for those who are willing to learn, seeing some extra work as the aforementioned long-term investment, and who have the patience reach a worthy goal a little later rather than right this very minute.

Stallmanagreed with that sentiment. But he would alsolike to see Emacs return to popularity as an editor of text for publication . Several noted that Org mode is already being used successfully for text-publication purposes. That mode isnot familiar to Stallman and he was unable to learn much about using it for word processing by reading the documentation. Zaretskiipointed out that there is a high barrier to learning Org mode from its documentation, at least for the word-processing use case.

Once again, though, it seems quite unlikely that some putative, well-documented word-processing Emacs mode is likely to have users flocking to the editor. But Stallmansaid that the user profile for Emacs was much broader 30 years ago; he would like to see it be that way again. He personally does not see rounded corners as part of that, though he is not opposed to efforts in that direction; " [...] if you want to attract more users to Emacs, I think there are more important areas for improvement. " Luhad some ideas along those lines, for example using starter kits (or packs) to help make the editor " more friendly to newcomers ".

There was a difference of opinion about making changes to the defaults, though, in order to help newcomers. If changes need to be made for the sake of newcomers, ndamesaid, established users can just turn them off. For example, Cua Mode , which adds the "standard" keybindings for things like cut and paste (i.e. ctrl-c, ctrl-x, ctrl-v) to Emacs, should be on by default; " it could make the life of new users easier if they didn't have to turn it on explicitly and they could use their copy/paste keys from the start like they are used it to in other tools ".

But Lusuggested adding a button for newcomers to turn on those features from the splash screen instead. Better still might be for Emacs to recognize a possible newcomer, ndamesuggested:

And if the user says no then everything is as usual.

There was some discussion of gathering feedback before deciding to change defaults and such, but Dmitry Gutovwondered if existing users are even relevant. If expanding the reach of Emacs is the goal, it may make sense to look at the problem differently:

And it's not like existing, long-time users can't grow to like the new defaults (even after a certain amount of grumbling).

Ludisagreed; " We should prioritize existing users over hypothetical users that don't even exist yet. " But Gutovsaid that might be shortsighted; " I don't want Emacs to die out, and it will if we don't do the work of attracting new users. " No real conclusion was reached; everyone would like to see the number of Emacs users (developers, testers, documentation writers, ...) grow, but how to do so is unclear at best.

Licensing

Back to rounded corners, Zaretskiisaid that the only thing standing in the way of that was code to implement it; " [...] patches to add such capabilities to Emacs are most welcome ". But Emacs is multi-platform, Gutovsaid, which means that buttons look different on each. Even on the same platform, different graphics toolkits give different looks—and the looks change between toolkit releases.

Alex Bennéesuggested that " unifying under a single cross-platform toolkit like GTK+ " would avoid some parts of the problem, but he also noted that a longstanding bug in GTK+ had caused him to use Emacs with the Lucid toolkit instead. He also worried about the next generation: " I've been thinking about text editors for my children to use as they graduate from point and click programming to proper text and even I'm not sure I want their first experience to be Emacs. "

Zaretskiipointed out that GTK+ is not really cross-platform. In addition, the bug in question is not considered to be one by the GNOME developers, which led Ulrich Mueller tomuse about a switch to Qt. But Stallman was quick to put the kibosh on that; Qt is only available for GPL 2 and 3, using it would mean that if there is a GPL 4 someday, Emacs could not switch to it. " So we must avoid using Qt. "

Electron was alsoraised as a possibility, but it turns out to have " freedom issues ", Lusaid. It is not clear how serious any of these ideas were; switching graphics toolkits is a decidedly non-trivial undertaking. It does seem like an indication that some in the Emacs development community are getting frustrated with the GUI version(s) of the editor. Beyond that, many of the Emacs developers do not even use the GTK+ version because of the bug, which leads to less interest in improving that version of Emacs; it all seems to be something of a mess.

The icons used by Emacs were also questioned in the thread, with licensing rearing its head there as well. The Emacs subreddit is apparently fertile ground for thoughts and suggestions as it came up a few times in the thread. For example, ndamereported " that a user posted a screenshot of an emacs toolbar with really sad looking icons at the end ". There are icon sets available under the GPL that could be used instead, they asserted. But Zaretskiicautioned that things may not be that clear-cut:

Feel free to point us to GPLed icons that can be incorporated in Emacs. At the time, the situation was nowhere as easy as you imply, but maybe things have changed since then.

Several icon sets were suggested, including GNOME icons, some from Wikimedia, and those from KDE, all of which are available under various free licenses (GPL, Creative Commons, LGPL). But there is more work to do than just identifying candidates, Zaretskiisaid:

Someone™ needs to invest the time and effort to figure out the legal issues, find the icons that we want out of those which are legally fit, and post the resulting information. We did that process at the time (AFAIR, quite a few of our icons come from Gnome/GTK), and it wasn't easy.

Alternatively, someone could create our own icons, in which case they could be even prettier than the ones pointed out here.

In any case, this is a non-trivial job, and volunteers are most welcome to do it. I don't think anyone is happy about the icons shown on the tool bar by Message mode; the only reason we use them is that we couldn't find better ones that are free and suitable for inclusion in Emacs.

But, ndameasked, shouldn't icons that come from GNOME, a longstanding free-software project, be perfectly acceptable to use in Emacs? Sadly, it is not so easy as that, Zaretskiisaid: " IANAL, but I think it has to be GPL v2+ at least. And perhaps we would also need the copyright assigned to the FSF. " For example, the Wikimedia icons are available under the the LGPLv3 and Creative Commons Attribution-ShareAlike (CC BY-SA) 3.0 licenses, but neither of those would work for pieces that are part of the Emacs program, Stallmansaid. Without the "or later" on the LGPL grant, the Qt problem would exist; CC BY-SA 3.0 " is incompatible with every version of the GPL ". But that may not matter in the end:

The Emacs distribution contains many works, including textual, art, and small programs, which are distinct from the program, Emacs.

Zaretskii and Stallman were able to determine that icons for Emacs fall into that category, so they simply need to be available under any free license, which should simplify things—if someone gets the time and energy to work on the problem. Like most projects, Emacs suffers from a shortage of human power; a project to improve the GUI that may not be widely used by those developers could go wanting. And that, in a lot of ways, sums up the situation with the editor project.

Moving forward

Emacs is quite useful for its adherents; many of them see it is their main interface to their computers. Others use it regularly but less universally. There are even longtime Vim users (who may have started on vi, in truth) that need Emacs for certain tasks—me for example. It serves all of these users well, but does it really still have a role in ten, twenty, or forty years? It is not an easy question to answer, of course; certainly it will still be with us in both ten and twenty years, but how many users will it have in forty?

Part of the problem is that the dedicated following for Emacs is also pretty resistant to change to any major degree. That's not meant as a knock of any sort, simply an observation. There are plenty of examples in that huge thread of ideas that were seemingly shot down because they represent change that might upset existing users. But it would seem that some changes of some sort are needed to bring in new blood. If few or no new users are coming in and nothing is done to attract more, it can only lead to eventual extinction.

Hopefully that is not the path that Emacs is on—or if it is, that it changes direction before (too) long. It is one of the earliest free-software programs in existence; pre-dating the term "free software" by nearly a decade, in fact. Of course, the code itself need never disappear entirely, but a vibrant—growing—Emacs community would be wonderful to see.

In truth, we have barely scratched the surface of that mega-thread. There are plenty of sub-threads that went completely unmentioned here; those interested in Emacs development—warts and all—will find plenty to read and digest there. Whether Emacs ends up with rounded corners or not seems like simply the tip of the iceberg of things that might need to be addressed to make Emacs more newcomer-friendly. How that can happen within that community remains to be seen.

(

to post comments)


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK