Giovanni Biscuolo <g...@xelera.eu> writes:
> [[PGP Signed Part:Undecided]] > Hello, > > ...I'm talking about Emacs. > > In <87bkdzssgm....@gmail.com> [1] Simon Tournier <zimon.touto...@gmail.com> > writes: > > [1] https://yhetil.org/guix/87bkdzssgm....@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....@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] https://yhetil.org/guix/87pm2e4flj....@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.
