WEBVTT
00:00.880 --> 00:02.386
Good afternoon. I'm Nicolas Rougier,
00:02.386 --> 00:04.080
and today I would like to present some of
00:04.080 --> 00:06.560
the experiments I've made with Emacs.
00:06.560 --> 00:08.400
My initial motivation was an
00:08.400 --> 00:09.920
inner feeling that something was
00:09.920 --> 00:12.559
wrong with most modern editors,
00:12.559 --> 00:14.559
and before I show you my experiment,
00:14.559 --> 00:16.004
I will try to demonstrate
00:16.004 --> 00:17.440
what I think is wrong.
00:17.440 --> 00:18.720
Note that this is mostly my
00:18.720 --> 00:20.640
personal feelings and I did not commit
00:20.640 --> 00:23.279
any experiment to test is this or
00:23.279 --> 00:25.279
that choice would be better.
00:25.279 --> 00:26.781
Of course, some of you might
00:26.781 --> 00:30.480
legitimately disagree with me.
00:30.480 --> 00:32.399
Let's start with a short review of a
00:32.399 --> 00:35.160
modern text editor. I chose Nova editor
00:35.160 --> 00:37.680
that is only available on OS X,
00:37.680 --> 00:39.920
but there are actually many other very
00:39.920 --> 00:42.960
similar editors, such as, for example,
00:42.960 --> 00:45.680
Atom, Sublime Text, or Visual Studio.
00:45.680 --> 00:47.760
Now it's quite interesting because I think
00:47.760 --> 00:50.239
it manages to gather everything what is
00:50.239 --> 00:53.120
wrong in this single screenshot that is
00:53.120 --> 00:55.920
also the teaser image on their website.
00:55.920 --> 00:58.160
So let me now review it according to my
00:58.160 --> 01:01.039
personal biases and for further analysis
01:01.039 --> 01:02.667
I can only recommend to attend
01:02.667 --> 01:05.680
David Wilson's talks tomorrow.
01:05.680 --> 01:07.360
The most (inaudible) thing that really
01:07.360 --> 01:11.583
bothers me is the actual area dedicated
01:11.583 --> 01:13.504
to the editing. When you measure
01:13.504 --> 01:15.553
this editing area as I did on the
01:15.553 --> 01:19.112
screenshot, you'll find an impressive 35%,
01:19.112 --> 01:22.316
which is ridiculously small
01:22.316 --> 01:24.240
compared to the side of the window.
01:24.240 --> 01:26.320
This means that two-thirds of the window
01:26.320 --> 01:30.079
area is dedicated to peripheral information
01:30.079 --> 01:32.079
that you don't look so often
01:32.079 --> 01:34.159
when writing code or prose.
01:34.159 --> 01:36.560
This results in the main editing area to
01:36.560 --> 01:39.119
be reduced to one third even if we tend
01:39.119 --> 01:42.040
to have larger and larger monitors, I think
01:42.040 --> 01:45.600
this is wrong to lost so much of space.
01:45.600 --> 01:47.759
If we now look closer at this peripheral
01:47.759 --> 01:49.920
information, we can immediately see that
01:49.920 --> 01:52.079
there is a lot of redundancy.
01:52.079 --> 01:53.617
For example, on the screenshot,
01:53.617 --> 01:55.709
I highlighted the information related
01:55.709 --> 01:57.759
to the file name being edited.
01:57.759 --> 02:00.640
Unless I missed, some this file name
02:00.640 --> 02:02.320
is displayed four times.
02:02.320 --> 02:04.399
This is way too much even if it
02:04.399 --> 02:06.320
displayed for different reasons
02:06.320 --> 02:08.959
in different contexts, but still I think
02:08.959 --> 02:10.720
you have a design problem if you need to
02:10.720 --> 02:14.560
repeat an information up to four times.
02:14.560 --> 02:15.947
If we now look at colors,
02:15.947 --> 02:18.160
you can count 15 different colors,
02:18.160 --> 02:20.560
such that it is impossible to guess
02:20.560 --> 02:22.959
which color indicates what.
02:22.959 --> 02:25.440
Such colorization based on syntax is
02:25.440 --> 02:28.720
actually quite widespread in code editors
02:28.720 --> 02:30.959
including Emacs, unfortunately.
02:30.959 --> 02:32.640
The problem is that we still don't know
02:32.640 --> 02:34.319
whether it helps or not.
02:34.319 --> 02:36.780
Some studies say yes, some others say no,
02:36.780 --> 02:38.239
and in the end the conclusion
02:38.239 --> 02:40.080
is not yet settled.
02:40.080 --> 02:41.840
Furthermore, there is another problem
02:41.840 --> 02:43.663
because there is no scientific method
02:43.663 --> 02:46.080
on how to enforce colonization.
02:46.080 --> 02:48.800
Should it be based on syntax, or semantic,
02:48.800 --> 02:51.519
or context, or something else?
02:51.519 --> 02:53.599
Developers are actually pretty free to do
02:53.599 --> 02:56.400
whatever they want, a lot of them will
02:56.400 --> 02:58.879
use syntax based colorization because it
02:58.879 --> 03:01.280
is the most simple to write.
03:01.280 --> 03:03.280
In the end, most of them achieve a
03:03.280 --> 03:06.080
Christmas tree effect.
03:06.080 --> 03:08.189
We know however, how to use colors
03:08.189 --> 03:10.560
to drag attention to a specific position
03:10.560 --> 03:13.920
as it is shown on the screenshot.
03:13.920 --> 03:15.760
This is called the pop-out effect,
03:15.760 --> 03:18.080
which is quite well known in neuroscience.
03:18.080 --> 03:20.000
Here, the media keyword has been
03:20.000 --> 03:23.120
made very silent just by setting
03:23.120 --> 03:25.760
the color in red while all other
03:25.760 --> 03:28.080
elements are desaturated.
03:28.080 --> 03:30.480
It literally pops out from the screen
03:30.480 --> 03:33.680
and point attention toward it.
03:33.680 --> 03:35.360
Finally, if we look at the overall
03:35.360 --> 03:36.879
structure of the Nova editor,
03:36.879 --> 03:39.353
we can characterize structural elements
03:39.353 --> 03:41.840
that are also present in a large number
03:41.840 --> 03:44.029
of modern editors namely,
03:44.029 --> 03:46.400
a file browser, a gutter, a mini map,
03:46.400 --> 03:47.844
a tab bar, a toolbar,
03:47.844 --> 03:49.920
and some versioning tools.
03:49.920 --> 03:52.477
I think this is too much information,
03:52.477 --> 03:54.879
and can lead to cognitive overload
03:54.879 --> 03:57.725
such that you end up to not pay attention
03:57.725 --> 03:59.599
to important information.
03:59.599 --> 04:02.720
So definitely more is not always better,
04:02.720 --> 04:05.280
and to paraphrase Edward Tufte in his book
04:05.280 --> 04:06.780
The Visual Display of
04:06.780 --> 04:08.720
Quantitative Information,
04:08.720 --> 04:12.560
"Above all else show the data."
04:12.560 --> 04:14.640
This is a reason that led me to
04:14.640 --> 04:16.720
experiment alternative design,
04:16.720 --> 04:18.079
and of course, to do that with
04:18.079 --> 04:19.840
the total freedom I didn't have
04:19.840 --> 04:24.080
much choice but to use and hack Emacs.
04:24.080 --> 04:27.001
My first iteration was called Elegant Emacs,
04:27.001 --> 04:29.271
and I try to enforce a few principles
04:29.271 --> 04:31.759
that I will detail into the next slide.
04:31.759 --> 04:33.919
But roughly, my idea was to
04:33.919 --> 04:35.857
enforce a radically different design
04:35.857 --> 04:38.320
by simply removing as much
04:38.320 --> 04:40.080
information as I could.
04:40.080 --> 04:42.240
Even so, vanilla Emacs is
04:42.240 --> 04:44.000
already quite simple.
04:44.000 --> 04:45.759
You can see the result on the screen,
04:45.759 --> 04:47.759
and I'm practically happy with the third
04:47.759 --> 04:50.240
screenshot that mimics the PDF layout of
04:50.240 --> 04:53.120
a scientific article by Stefan Monnier
04:53.120 --> 04:55.360
and Michael Sperber but rather
04:55.360 --> 04:58.160
fully inside Emacs.
04:58.160 --> 05:01.080
The second iteration is called NANO Emacs,
05:01.080 --> 05:03.680
and it is a version I try to maintain
05:03.680 --> 05:05.592
with a set of standalone packages
05:05.592 --> 05:07.759
that you can test individually.
05:07.759 --> 05:09.271
It is based on a set of
05:09.271 --> 05:11.919
a few principles, namely
05:11.919 --> 05:14.677
large margins, reduced number of faces,
05:14.677 --> 05:17.360
a simplified and contextual header line,
05:17.360 --> 05:19.280
and a default aspect ratio that
05:19.280 --> 05:21.759
mimics the A4 ISO format.
05:21.759 --> 05:24.240
I've been using this layout for a
05:24.240 --> 05:26.720
year and so far I'm quite happy with it.
05:26.720 --> 05:29.440
I know this is quite an opinionated
05:29.440 --> 05:31.680
design and some of you may totally
05:31.680 --> 05:34.240
disagree with me.
05:34.240 --> 05:36.630
Lately I've been experimenting
05:36.630 --> 05:38.682
with some special modes where
05:38.682 --> 05:41.919
the header line is made even simpler,
05:41.919 --> 05:44.080
this is the case for org-agenda,
05:44.080 --> 05:46.720
mu4e, deft, and elfeed.
05:46.720 --> 05:48.560
This worked reasonably well
05:48.560 --> 05:50.952
because these modes are search based,
05:50.952 --> 05:54.720
and it was easy to unify their design.
05:54.720 --> 05:56.960
I've also integrated some dynamic tags
05:56.960 --> 06:00.484
and icon in my agenda using svg-lib,
06:00.484 --> 06:02.400
which is available on ELPA.
06:02.400 --> 06:04.960
And for example, you can see the
06:04.960 --> 06:08.560
pie progress that help to show
06:08.560 --> 06:11.440
some incoming deadlines.
06:11.440 --> 06:13.261
There are still ongoing development
06:13.261 --> 06:15.120
to develop new packages to give
06:15.120 --> 06:17.280
a unified look and feel.
06:17.280 --> 06:18.792
I got a lot of feedback from
06:18.792 --> 06:20.768
the Emacs community,
06:20.768 --> 06:22.288
mostly in Reddit and GitHub,
06:22.288 --> 06:24.319
and I would like to thank them here
06:24.319 --> 06:26.880
because this is incredibly useful.
06:26.880 --> 06:29.039
If you want to follow or support my work,
06:29.039 --> 06:31.600
best place is probably GitHub.
06:31.600 --> 06:33.099
Thank you for your attention.
06:33.099 --> 06:34.479
I will be happy to answer
06:34.479 --> 06:36.874
any questions you may have.
06:36.874 --> 06:38.520
[captions by bhavin192 (Bhavin Gandhi)]
