summaryrefslogtreecommitdiffstats
path: root/2021/talks/design.md
diff options
context:
space:
mode:
Diffstat (limited to '2021/talks/design.md')
-rw-r--r--2021/talks/design.md115
1 files changed, 115 insertions, 0 deletions
diff --git a/2021/talks/design.md b/2021/talks/design.md
new file mode 100644
index 00000000..84a89de9
--- /dev/null
+++ b/2021/talks/design.md
@@ -0,0 +1,115 @@
+[[!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.
+
+- From [YouTube](www.youtube.com/watch?v=7OTe26RZH9A&feature=em-comments): 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
+* 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"]]