summaryrefslogblamecommitdiffstats
path: root/2020/schedule/21.md
blob: 2bcf641e8fe2186ed4ccd47062793b5efb3c05a9 (plain) (tree)
1
2
3
4
5
6
7
8
9



                                                                                  

                                                                         

 
                                                                  
                                                                                                                                                        






















































                                                                      
 
                          

                                                                         






                                                                                         
[[!meta title="On why most of the best features in eev look like 5-minute hacks"]]
[[!meta copyright="Copyright © 2020 Eduardo Ochs"]]

Back to the [[schedule]]  
Previous: <a href="/2020/schedule/08">Building reproducible Emacs</a>  
Next: <a href="/2020/schedule/09">Orgmode - your life in plain text</a>  


# On why most of the best features in eev look like 5-minute hacks
Saturday, Nov 28 2020, 11:47 AM - 12:27 PM EST /  8:47 AM -  9:27 AM PST /  4:47 PM -  5:27 PM UTC /  5:47 PM -  6:27 PM CET / 12:47 AM -  1:27 AM +08  
Eduardo Ochs

In the last months there were several hundreds of messages in
emacs-devel in threads with names like "A proposal for a friendlier
Emacs", "How to make Emacs popular again", and "Interactive guide for
new users".  On the one hand I am absolutely sure that eev is very
good answer to all these themes; on the other hand I know that eev is
based on some design decisions that offend most people used to modern,
"user-friendly" interfaces - and I feel that at this moment mentions
to eev in those discussions in emacs-devel would not be welcome.

In this talk I will start by presenting very quickly the main "killer
features" of eev - namely:

1.  Elisp hyperlinks,

2.  interactive tutorials that can be navigated with just three keys,

3.  non-invasiveness - people can easily turn eev on for only five
    minutes each week, play with it a bit, and then turn it off,

4.  high discoverability factor,

5.  a way to create "hyperlinks to here",

6.  hyperlinks to specific points in PDF documents and video files -
    i.e., to specific pages, strings, and timemarks,

7.  a way to control shell-like programs ("eepitch"), and

8.  an Elisp tutorial,

and after that I will present the design decisions behind eev, in two
parts:

1.  eev is a very thin layer above Emacs-the-Lisp-environment; it is
    as simple as possible, but in the sense of "simple" that was used
    in Forth, and that is not very familiar today.

2.  Very often when I am using Emacs - which is my main interface
    with the system - I realize that I can automate some task that I
    just did by hand twice of thrice; and that I should do that,
    because automating that would be both easy and fun.  Over the
    years I experimented with several ways of automating tasks,
    refined some of these ways a lot, and found a certain "best"
    style that, again, usually offends people who are accustomed with
    the modern ideas of user-friendliness.  In this style, used in
    most template-based functions in eev, both textual documentation
    and error-handling are kept to a minimum.  I will show how, and
    why, eev makes this style works so well, and how users can create
    their own templated functions very quickly - as "5-minute hacks".





Back to the [[schedule]]  
Previous: <a href="/2020/schedule/08">Building reproducible Emacs</a>  
Next: <a href="/2020/schedule/09">Orgmode - your life in plain text</a>  


All times are approximate, and we might shuffle talks around as needed.
Please check <https://emacsconf.org/2020> a few days before the start of the
conference for instructions on how to watch and participate. See you then!
<!-- automatically generated from submissions.org using conf/generate-schedule-files --->