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 colonization.
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 silent 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)]