summaryrefslogtreecommitdiffstats
path: root/2021/talks/design.md
blob: 3ff29daf29bdb1fd290befe1f2bab486d170937e (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
[[!meta title="On the design of text editors"]]
[[!meta copyright="Copyright © 2021 Nicolas P. Rougier"]]
[[!inline pages="internal(2021/info/design-nav)" raw="yes"]]

<!-- You can manually edit this file to update the abstract, add links, etc. --->


# On the design of text editors
Nicolas P. Rougier



[[!inline pages="internal(2021/info/design-schedule)" raw="yes"]]

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:

* [Elegant Emacs](https://github.com/rougier/elegant-emacs) (https://github.com/rougier/elegant-emacs)
* [On the Design of Text Editors](https://arxiv.org/abs/2008.06030) (https://arxiv.org/abs/2008.06030)
* [N Λ N O Emacs](https://github.com/rougier/nano-emacs) (https://github.com/rougier/nano-emacs)
* [svg-lib (ELPA)](https://elpa.gnu.org/packages/svg-lib.html) (https://elpa.gnu.org/packages/svg-lib.html)
* [nano-theme (ELPA)](https://elpa.gnu.org/packages/nano-theme.html) (https://elpa.gnu.org/packages/nano-theme.html)
* [nano-modeline (ELPA)](https://elpa.gnu.org/packages/nano-modeline.html) (https://elpa.gnu.org/packages/nano-modeline.html)
* [nano-agenda (ELPA)](https://elpa.gnu.org/packages/nano-agenda.html) (https://elpa.gnu.org/packages/nano-agenda.html)

# 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?
    -   A: <https://github.com/plexus/chemacs> is a perfect answer. It
        allows you to switch from one configuration to another without
        messing up your own.
-   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.

# Contact information
* Contact [nicolas.rougier@inria.fr](mailto:nicolas.rougier@inria.fr)
* Follow my work at [github.com/rougier](https://github.com/rougier)
* Support my work at [github.com/sponsors/rougier](https://github.com/sponsors/rougier) or [en.liberapay.com/rougier/](https://en.liberapay.com/rougier/)

[[!inline pages="internal(2021/captions/design)" raw="yes"]]

[[!inline pages="internal(2021/info/design-nav)" raw="yes"]]