Re: [emacs-humanities] Emacs as a Unix citizen

[Paul W. Rankin]

I've been meaning to contribute to this conversation for a while. I 
liked Prot's blog post, and I also found this blog where the author 
James Norman Vladimir Cash talks about how the bloat-vs-minimalism thing 
in software has a political angle that might interest our Humanities 
Crowd: 
https://occasionallycogent.com/against_mindless_minimalism/index.html

There is definitely an emotional lure to the everything-within-Emacs 
approach. I think we all want to use a tool to its greatest efficiency, 
e.g. if you bought a coffee machine that could froth milk but you only 
drank black coffee you'd probably yearn for a friend to ask for a 
cappuccino... An Emacs that can make cappuccinos but is just sitting 
there *not* making cappuccinos seems like lost efficiency. Leaving money 
on the table! It feels good to navigate to the edges of a tool's 
capabilities. It feels like mastery.

I think this is part of the feeling you get when you put your whole life 
into org-mode. There's a sense that if you can just reach the edges, 
where there's nothing more that can get organised, then you'd have a 
handle on the thing. Or at least I did. The horizon always seemed just a 
little bit further. (I use a paper notebook now, but this isn't to cast 
my lot one way or the other, just musing.)

I do think of Emacs as a Good Unix Citizen, but I tend to see it as 
three parts, which are usually seen as one...

There's Emacs the text editor, which is written in C, quite small 
(222,240 unique lines of code by my count [1]) and immutable during use. 
It has an interpreter for its own customisation code: Emacs Lisp. Then 
there are the Elisp programs, either included or as packages.

The focus of Elisp as a programming language is quite narrow: it doesn't 
do (or doesn't do well) the fancy things I hear that other languages do, 
but it has core concepts like point, region, buffers, and windows. As a 
language it does one thing well: manipulates text within Emacs (whether 
a text file or a textual interface).

Then Elisp programs also tend to do one thing well, e.g. builtin 
delete-selection-mode is a minor mode that when enabled makes typed text 
replace the selection. When I was making screenwriting major mode 
fountain-mode I added a feature to balance the window margins, then 
realised this should be its own one-thing-well minor mode: olivetti, 
which is now more popular than its parent. Monolithic things like 
org-mode and gnus tend to be the outliers. When an Elisp program needs 
to do some heavy lifting, it's almost always best to delegate this to an 
external program, e.g. spellchecking works via external aspell, the 
email program mu4e is really just a text UI for the mu program.

So, text editor, Elisp language, Elisp programs. Each does one thing 
well.[2]

[1] $ cat src/*.c src/*.h | LANG=C sort -bu | wc -l
[2] We could also remember that GNU is Not Unix.


On 2020-12-29 05:28, Oliver Taylor via Emacs-humanities wrote:
> I thought Prot's comments on how Emacs fits in to a Unix-centric
> workflow[1] were interesting, and I thought I'd share my take on it.
>
> 1: https://protesilaos.com/codelog/2020-12-28-comment-unix-vs-emacs/
>
> Different computing environments have different interaction methods. 
> The iPad
> is one, the GUI (mouse and keyboard) is another, UNIX yet 
> another---Firefox
> works the same way everything else in the GUI works, sed works the same 
> way
> everything in UNIX works. It is tempting to think that software that is 
> a
> 'good citizen' of its environment should follow the conventions of that
> environment, and for the most part I enthusiastically agree. Under that 
> line
> of thinking Emacs seems strange indeed, it does not follow the strict
> conventions of a GUI, nor of UNIX. But Emacs is, in fact, less a 
> citizen of
> those environments and more an environment unto itself. In my view this 
> is the
> source of the confusion: to use Emacs is to (in effect) embed one 
> computing
> environment within another (somewhat like VNC-ing into a Windows 
> machine from
> an iPad). Switching between Firefox, Terminal, and Emacs requires three
> completely different interaction methods, unique to each program. I can
> certainly understand why one would not want to do this but it does not 
> bother
> me, and allows me to use the best tool for the job at hand (which 
> reminds me
> somewhat of the vim koan of Master Wq and the Windows developer[2]).
>
> 2: https://sanctum.geek.nz/arabesque/vim-koans/
>
> Personally, my answer to the question 'Why use Emacs?' is:
>
> * Ease, and completeness, of customization and extension.
>
> I imagine Emacs users nodding in agreement with this statement and 
> non-Emacs
> users scratching their heads in confusion. Emacs can seem complex, but 
> once
> you learn how to customize and extend it an enormous (and highly 
> accessible)
> landscape opens up. The sheer breadth and depth of the possibilities to
> customize and extend are what makes Emacs unique, and allows Emacs to
> transcend being 'just' a text editor.