Re: The elephant in the room and the Guix Bang.

[Csepp]

Giovanni Biscuolo <g@xelera.eu> writes:

> [[PGP Signed Part:Undecided]]
> Hello,
>
> ...I'm talking about Emacs.
>
> In <87bkdzssgm.fsf@gmail.com> [1] Simon Tournier <zimon.toutoune@gmail.com> 
> writes:
>
> [1] 87bkdzssgm.fsf@gmail.com/">https://yhetil.org/guix/87bkdzssgm.fsf@gmail.com/
>
> [...]
>
>> people are already engaging for improving the accessibility of editors
>> other than Emacs
>
> Simon gave me the opportunity to realize (once again) that IMO there is
> a foundamental misconception regarding Emacs.
>
> What is Emacs, exacly: is it an editor?
>
> I feel that a great deal of friction on the matter is due to the fact
> that Emacs is usually defined as an /editor/ (OK text editor, but it
> makes no difference)... **also** in its official page:
>
>
>  An extensible, customizable, free/libre text editor — and more.
>  
>  At its core is an interpreter for Emacs Lisp, a dialect of the Lisp
>  programming language with extensions to support text editing.
>
> (https://www.gnu.org/software/emacs/)
>
> IMO to define Emacs as a sort of «text editor on steroids with batteries
> included (Emacs Lisp)» does not represent the real nature of the
> program; an /effective/ definition would be:
>
>
>  An extensible, customizable, free/libre user interface.
>  
>  At its core is an interpreter for Emacs Lisp, a dialect of the Lisp
>  programming language, with extensions to use it as an interface to text
>  editing functions and many, many more: MUA, web browser, task
>  organizer...
>
>
> To define Emacs as a /user interface/ it's not just a cool way to
> "market it", it means to classify its /unique/ (?) user interface design
> as one among all the historical instances of user interfaces:
>
>
> 1. batch interface
> 2. command line interface
> 3. SAA User Interface or Text-Based User Interface
> 4. graphical user interface
> 5. (editor note) web user interface
>
> (https://en.wikipedia.org/wiki/User_interface#History)
>
> Someone may consider Emacs "just" a "text-based user interface (UI)"
> (point 3. of the above mentioned list) like the ones using curses and
> alike (e.g. vim, mutt, ranger, Norton Commander and so on) but IMO Emacs
> implements a very different design, centered around a specific UI
> element called "emacs buffer".
>
> I consider Emacs as a 6th class of user interface :-D
>
> Just to bring my limited personal experience: I was a mutt+vim user for
> email management, ranger for file management... and so on, and since I
> was was **very** happy with my vim user experience when editing text,
> for a very long time I looked at Emacs as "just" another text editor I
> didn't need, because **as text editors** both vim, Emacs and alike are
> /very/ powerful and I was never ever interested for just a sec to the
> funny "editor war" (and similar "wars").
>
> Then, one day, moved by curiosity and the fact that the Emacs interface
> is /integrated/ in the notmuch mail indexer I was already using, I
> started using Emacs as my preferred /user interface/ for notmuch... and
> some year later here I am, trying to use the Emacs interface for as much
> computing activities I can.
>
> Now I see Emacs in a very different way.
>
> Incidentally (?), AFAIU Emacs was the Guile IDE (integrated development
> environment, not text editor) used by Ludovic when he started
> programming Guix; he and probably some (many?) of the contributors was
> so happy with their tool that they started sharing their configuration
> snippets, as usual amoung a community of enthusiastic users... after
> many refinements and maybe some Emacs extentions progamming, they was so
> proud that they decided to recommend the same (set of) tool /and/
> configuration to other _collegues_, the famous "perfect setup" described
> in the Guix manual.
>
> I'm also suspecting that the spark that started the "Guix Bang" in
> Ludovic's mind, the very moment he realized nix could be better
> _extended_ using Guile in place of it's DSL, was /caused/ by the fact he
> was a Lisp programmer, the specific /dialect/ probably did not matter.
> But I'm just guessing.
>
> Now I see Guix in a different way. :-)
>
> In this context: is the Guix project biased in recommending using Emacs
> (a Lisp interpreter and compiler for Emacs Lisp) to contributors?  I
> don't think so.
>
> I'd rather say that - as in many other organizations and all similar
> projects - Guix adopts a "BYOT" (bring your own tool) organizational
> policy... and the first contributors brought theirs. :-D
>
> For sure vim/neovim - and other tools - can also be extended and *used*
> to provide /user interface/s for various external tools (e.g. see
> fugitive.vim/nvim-fugitive) that are useful when using and/or developing
> Guix, everyone is free to use and extend them, and also to share with
> the whole Guix community how their beloved BYOT are working well.
>
> Please see a recent message of mine (id:87pm2e4flj.fsf@xelera.eu [2])
> for some of my comments (nothing really new, I just reused concept
> already expressed by others) about the process needed to integrate
> useful informations (configuration _is_ information) in Guix
> official _recommandations_.
>
> Happy hacking! Gio'
>
> [2] 87pm2e4flj.fsf@xelera.eu/">https://yhetil.org/guix/87pm2e4flj.fsf@xelera.eu/

Recommending Emacs would IMHO be fine, iff the UX wasn't so bad.  It's
better if we have at least one *well documented* developer setup, than
if we have a bunch of (sometimes conflicting) partial docs for setting
up certain subsystems.
Emacs can be pretty good, once you do (setq make-defaults-not-suck 1) a
bunch of times.