Back to the schedule
Previous: Emacs development updates
Next: Closing remarks day 1

On the design of text editors

Nicolas P. Rougier

Q&A: maybe live
Duration: 6:39

This talk was also streamed at an alternate time for APAC hours: https://libreau.org/past.html#emacsconf21

If you have questions and the speaker has not indicated public contact information on this page, please feel free to e-mail us at emacsconf-submit@gnu.org and we'll forward your question to the speaker.

Talk

Download video, 6:39, 9.3M

Download --compressed56.webm (6.5MB)
Download --main.vtt
View on Toobnix

Q&A

Download video, 6:34, 17.4M

Description

Text editors are written by and for developers. They come with a large set of default and implicit choices in terms of layout, typography, colorization and interaction that hardly change from one editor to the other. It is not clear if these implicit choices derive from the ignorance of alternatives or if they derive from developers' habits, reproducing what they are used to. Durint this talk, I will characterize these implicit choices and illustrate what are some alternatives using GNU Emacs.

Outline

  1. Review of a "modern" code editor (5mn)
  2. Introduction of an alternative using Emacs (5mn)

Links from the slides:

Discussion

  • Q1: Do you have any plans for somewhat scientific testing of colors, layout, etc?
    • A: There are already some studies on the usefulness of colorization but they're not consistent. I would love to make a study with some students but it's a bit beyond my expertise.
  • Q2: I have really enjoyed looking at the development of NANO emacs. The only thing I slightly disagree with are the colours: on my system some of them are extremely low-contrast and faded. Otherwise the design is fantastic! Do you have any comments on the colour scheme?
    • A: I think you're right and I might need to revise the color scheme, taking inspiration (or copying) some of the colors from modus themes since Prot designed proper colors backed by scientific theory.
  • Q3: Are your examples hand-selected from design-perspective or does "everything" look good automatically with your setup?
    • A: Screenshots I've shown are available on GitHub and you should obtain the same if you install them. Some parts come from my personal configuration (org-agenda and mu4e mostly) but I can post the code if you're interested.
  • Q4: Should we use monocromatic colour schemes over full-coloured ones?
    • A: I'm not sure I can answer this question, I would need to search if there are any recommendation on that matter.
  • Q5: Are there ways that emacs could be improved to make these kinds of usability experiments easier and more accessible to users? For example making it easier to switch between such experiments?
  • Q6: Would it be possible to integrate nano emacs design to default emacs design? What would the pushback be for integrating "better" UI changes?
    • A: I think Emacs would benefit from better defaults and I would vote for modus themes to be the new default theme. Next would be to package Emacs with a decent font (e.g. Julia Mono, Iosevka, Inconsolata, Victor Mono) that would really help changing the first impression of new users. Last would be to tweak a the mode-line a bit.

  • Q7:Spellchecking now highlights the whole word, to me this is a bit too emphasized. Are there plans to make these less intrusive; i.e. underline or similar? (And no, no bright red crinkles ;)

    • A: Good point, can you open an issuer on GitHub?

  • What's this theme?

  • i'll be sharing this with my friends that praise on vscode
  • Wow, incredible analysis of that editor.
  • looks beautiful
  • how much of that is just bigger margins and roboto though?
  • I love nano Emacs. I use it too
  • i wonder if I can steal the splash screen and header line
  • I really think that the default emacs theme could use this kind of effort and scrutiny in order to improve it
  • A4: good idea, but few people have A4 screens...
  • holy crap it looks so good
  • yet again, though, the contrast is awful! black and white, please, not light grey and not-quite-so-light grey. it's almost unreadable, IMHO
  • How hard would it be to integrate nano emacs changes with the default emacs? Like, would there be a lot of pushback?
    • of course! there was massive pushbac over using curly quotes, for goodness' sake
  • Are you aware of the modus-themes and what are your thoughts after contrast and accessibility?
    • yeah, i just love modus themes by Prot because i'm colorblind and the fact that it has a strict contrast ratio is really really helpful, but even on modus themes i have to set success, error and warning to some really strong colors like pure red, green and blue
      • I'm not colourblind and having high contrast is still good! there's a reason books are black on white, not grey on grey. or at least the background and body-text foreground must be highly distinct
        • protesilaos: there are also options for deuteranopia, in case you need them (will need to refactor them for simplicity's sake)
  • What Nicolas Rougier does is most welcome. Emacs can benefit a lot from such work.
  • hmmm maybe Emacs needs to be able to handle WOFF! sounds like a job for fontconfig, I might look at it some day

  • Nano Emacs + modus-themes would be a perfect combination, as it were.

  • From YouTube: Great efforts & I'm rooting for you! but you might consider rebranding, because of the GNU nano text editor (22 years of recognition)

Contact information

Transcript

Good afternoon. I'm Nicolas Rougier, and today I would like to present some of the experiments I've made with Emacs. My initial motivation was an inner feeling that something was wrong with most modern editors, and before I show you my experiment, I will try to demonstrate what I think is wrong. Note that this is mostly my personal feelings and I did not commit any experiment to test is this or that choice would be better. Of course, some of you might legitimately disagree with me. Let's start with a short review of a modern text editor. I chose Nova editor that is only available on OS X, but there are actually many other very similar editors, such as, for example, Atom, Sublime Text, or Visual Studio. Now it's quite interesting because I think it manages to gather everything what is wrong in this single screenshot that is also the teaser image on their website. So let me now review it according to my personal biases and for further analysis I can only recommend to attend David Wilson's talks tomorrow. The most (inaudible) thing that really bothers me is the actual area dedicated to the editing. When you measure this editing area as I did on the screenshot, you'll find an impressive 35%, which is ridiculously small compared to the side of the window. This means that two-thirds of the window area is dedicated to peripheral information that you don't look so often when writing code or prose. This results in the main editing area to be reduced to one third even if we tend to have larger and larger monitors, I think this is wrong to lost so much of space. If we now look closer at this peripheral information, we can immediately see that there is a lot of redundancy. For example, on the screenshot, I highlighted the information related to the file name being edited. Unless I missed, some this file name is displayed four times. This is way too much even if it displayed for different reasons in different contexts, but still I think you have a design problem if you need to repeat an information up to four times. If we now look at colors, you can count 15 different colors, such that it is impossible to guess which color indicates what. Such colorization based on syntax is actually quite widespread in code editors including Emacs, unfortunately. The problem is that we still don't know whether it helps or not. Some studies say yes, some others say no, and in the end the conclusion is not yet settled. Furthermore, there is another problem because there is no scientific method on how to enforce colorization. Should it be based on syntax, or semantic, or context, or something else? Developers are actually pretty free to do whatever they want, a lot of them will use syntax based colorization because it is the most simple to write. In the end, most of them achieve a Christmas tree effect. We know however, how to use colors to drag attention to a specific position as it is shown on the screenshot. This is called the pop-out effect, which is quite well known in neuroscience. Here, the media keyword has been made very salient just by setting the color in red while all other elements are desaturated. It literally pops out from the screen and point attention toward it. Finally, if we look at the overall structure of the Nova editor, we can characterize structural elements that are also present in a large number of modern editors namely, a file browser, a gutter, a mini map, a tab bar, a toolbar, and some versioning tools. I think this is too much information, and can lead to cognitive overload such that you end up to not pay attention to important information. So definitely more is not always better, and to paraphrase Edward Tufte in his book The Visual Display of Quantitative Information, "Above all else show the data." This is a reason that led me to experiment alternative design, and of course, to do that with the total freedom I didn't have much choice but to use and hack Emacs. My first iteration was called Elegant Emacs, and I try to enforce a few principles that I will detail into the next slide. But roughly, my idea was to enforce a radically different design by simply removing as much information as I could. Even so, vanilla Emacs is already quite simple. You can see the result on the screen, and I'm practically happy with the third screenshot that mimics the PDF layout of a scientific article by Stefan Monnier and Michael Sperber but rather fully inside Emacs. The second iteration is called NANO Emacs, and it is a version I try to maintain with a set of standalone packages that you can test individually. It is based on a set of a few principles, namely large margins, reduced number of faces, a simplified and contextual header line, and a default aspect ratio that mimics the A4 ISO format. I've been using this layout for a year and so far I'm quite happy with it. I know this is quite an opinionated design and some of you may totally disagree with me. Lately I've been experimenting with some special modes where the header line is made even simpler, this is the case for org-agenda, mu4e, deft, and elfeed. This worked reasonably well because these modes are search based, and it was easy to unify their design. I've also integrated some dynamic tags and icon in my agenda using svg-lib, which is available on ELPA. And for example, you can see the pie progress that help to show some incoming deadlines. There are still ongoing development to develop new packages to give a unified look and feel. I got a lot of feedback from the Emacs community, mostly in Reddit and GitHub, and I would like to thank them here because this is incredibly useful. If you want to follow or support my work, best place is probably GitHub. Thank you for your attention. I will be happy to answer any questions you may have. captions by bhavin192 (Bhavin Gandhi)

Back to the schedule
Previous: Emacs development updates
Next: Closing remarks day 1