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)]