Toward a "modern" Emacs
The May 2020 discussion focused on restoring the popularity that Emacs is felt to have enjoyed in the past. It could well be that there are more Emacs users now than at any time in the past but the editor's share of the total computing user base has clearly shrunk over time. The current discussion has a similar but different focus: attracting new users to Emacs, an editor that is widely seen as being outdated and as having a difficult and intimidating learning curve.
A more modern Emacs
The initial thread was started by "Ergus" on September 6 as a request to consider some changes for the Emacs 28 release. Rather than focus on new features, though, Ergus proposed making some existing features more accessible:
Many of the suggestions reverberated through the following discussions,
starting with the idea that the default theme for Emacs should be
improved. In particular, Ergus suggested the adoption of a dark theme by
default "to make Emacs feel more modern
". The discussion
often returned to the idea that Emacs needs a more "modern" look and feel,
though there was, understandably, some difference of opinion over what
"modern" means.
A default dark theme may not be in the future, leading one to think that there may yet be hope for the world in general. But there does seem to be general agreement that Emacs could benefit from a better, more centralized approach to color themes, rather than having color names hard-coded throughout various Elisp packages. From that, a proper theme engine could be supported, making dark themes and such easily available to those who want them.
There was some discussion of adopting the Solarized color palette in particular. As Dmitry Gutov pointed out, though, Solarized makes for a rather low-contrast experience; a look at this screenshot of Emacs with Solarized colors makes that clear enough.
Another area where Emacs is insufficiently "modern", it seems, has to do with keyboard and mouse bindings. On the keyboard side, users have come to expect certain actions from certain keystrokes; ^X to cut a selection, ^V to paste it, etc. These bindings are easily had by turning on the Cua mode, but new users tend not to know about this mode or how to enable it. Many participants in the discussion said that this mode should be on by default.
That, of course, would break the finger memory of large numbers of existing Emacs users, who would be unlikely to appreciate the disruption. Or, as Richard Stallman put it:
For better or worse, though, the "newer editors" appear to have won out in this regard. The default bindings in Emacs may not change anytime soon, but that doesn't mean Emacs can't provide a way for users to get that behavior without needing to learn Lisp first.
The situation with mouse behavior is similar; as several participants in the discussion pointed out, users of graphical interfaces have come to expect that a right-button click will produce a menu of available actions. In Emacs, instead, that button marks a region ("selection"), with a second click in the same spot yanking ("cutting") the selected text. Many experienced Emacs users have come to like this behavior, but it is surprising to newcomers. The right mouse button with the control key held down does produce a menu defined by the current major mode, but that is evidently not what is being requested here; that menu, some say, should present global actions rather mode-specific ones.
Stallman suggested
offering a "reshuffled mode
" that would bring the context menu
to an unadorned right-button click, and which would add some of the
expected basic editing commands there as well. This would be relatively
easy to do, he said, since mouse bindings are separate from everything
else. Besides, as he noted, the
current mouse behavior was derived from "what was the standard in X
Windows around 1990
"; while one wouldn't want to act in haste, it
might just be about time for an update.
Discoverability
In general, Emacs has all of the capabilities that new users might wish to
have (and more), but those capabilities can be difficult to discover and use. So a
number of the proposed changes had to do with easing discovery. This came
as an apparent surprise to some Emacs developers, who have long thought of
the menu bar at the top of each window as being an easy way for users to
discover features. But evidently it is common to disable the menu bar for
Emacs; as Gregory Heytings put
it, "menus are not 'modern'
". To be "modern", an
application must either attach its menus to the right mouse button or, at
most, provide a "hamburger menu" from a single button.
Emacs could certainly move to that mode, at least until menu bars are
fashionable again. But there are other ideas for improving discoverability
circulating as well. One of those would be to offer a "guided tour" to new
users upon the first invocation of the editor that would quickly introduce
core Emacs features; this would be an enhancement of the tutorial that
exists now. There was also a discussion of producing a series of videos,
or perhaps just making use of the many videos that exist now. Stefan
Monnier suggested
short videos to match the perceived attention span of young users,
"ideally funny and sexy, maybe with a cat
".
A step beyond the guided tour would be some sort of "configuration assistant" that would run on the first invocation of Emacs. It could offer tours, but it would also give the user the opportunity to configure the editor in ways that might better match their expectations. Features like Cua mode could be enabled, for example, mouse bindings adjusted, and a depressing dark theme selected without the need to type a single parenthesis. That might be enough to overcome the initial shock of exposure to Emacs for many new users.
One other suggestion that was raised frequently is to enable various modes that are not turned on by default in Emacs; indeed, several of them are not shipped with Emacs at all. For example, Ibuffer is generally seen as superior to the standard Emacs buffer list, so many think it should replace the standard list. The Emacs "undo" mechanism is more capable than what is provided in many other editors, but it is also seen as difficult to use; some users think that the undo-tree mode makes undo easier and should be shipped with Emacs and enabled by default. There are several modes that enhance the editor's command-search and autocompletion capabilities, including Ivy, Helm, and Ido, among others. Many of these, it is argued, provide behavior more in line with current expectations and improve discoverability; one of them should be adopted and made the default.
Attracting developers
One problem with many of these packages is that they are not actually a part of GNU Emacs. Changing that would often require the author to sign copyrights over to the Free Software Foundation, which is not something all authors are willing to do. Similar problems arise with many of the derivative Emacs "distributions", such as spacemacs or Doom, which have clearly eased the path into Emacs for some users. Some of the ideas found in these distributions may well merit inclusion in Emacs, but that does not happen. Emacs maintainer Eli Zaretskii complained that the creators of these distributions do not contribute their work back.
This points to one idea that did not really come up in the discussion, but
which should be considered: part of the key to making Emacs more attractive
to users might be making its development community more attractive to
contributors. Adopting some of the more forge-oriented tools favored by
younger developers might help in this regard, as might a less centralized
governance model. Emacs remains an old-style GNU project, a fact which
clearly grates on
its developers at times. Increasing the relevance of Emacs in the coming
years is going to require more than new key bindings and some cat videos;
it is likely to require attention to improving the experience at all
levels.