Re: Emacs users a dying breed?

[Philipp Haselwarter]

On Mon, Jun 18 2012 20:53 (@1340045620), Ugly Sean wrote:

> -----Original Message-----
> From:  jidanni@jidanni.org
> Sent: Monday, June 18, 2012 14:14
> To: help-gnu-emacs@gnu.org
> Subject: Re: Emacs users a dying breed?
>
>>Too late in the game to have me learn a different editor.
>
> If you are capable of learning then it's not too late.
> However, if Emacs is the editor you know, why bother changing?

You can't really know until you've tried, right? I sometimes wonder what
it's like on the other side… for two reasons:

1) Text editing actually seems quite efficient in the land of 666;
vimgolf [1] might or might not be representative, but the challenges and
results [2] are quite interesting. As Mickey Petersen puts it [3]:

> It’s obvious to most of us that to attempt a “fewest possible
> keystrokes” exercise in Emacs will invariably end in tears, as we
> can’t compete against vim in that regard; but with that said, we do
> have a lot of tricks up our sleeve.


And, more importantly,

2) Unix philosophy, in Doug McIlroy's words [4]:

> This is the Unix philosophy: Write programs that do one thing and do
> it well. Write programs to work together. Write programs to handle
> text streams, because that is a universal interface.

Eric Steven Raymond's "The Art of Unix Programming" discusses
editors [5] and the "Emacs question" in particular [6]:

> Emacs could be considered a virtual machine or framework around a
> collection of small, sharp tools (the modes) that happen to be written
> in Lisp.

Emacs does not contradict the philosophy /per se/, but sometimes I wish
Emacs was more of a low level utility. As it stands, Emacs does many
small tasks very well. One aspect that makes the workflow particularly
pleasant is that all these tools work together so well. Take the
kill-ring for example: It is by far the most powerful clipboard facility
I've used. But I'd like to be able to use it in all my applications, not
only those written in elisp. Emacs' entirely customizable key system is
another example of a tool that I'd like to have everywhere on my
desktop.

As it currently stands, all of the (elisp) programs that want to
leverage the power of Emacs' "global facilities" have to run in the same
main process. But there is a price to pay for mixing the core features
with the high-level programs:

 - concurrency/locking
   the classic example being programs that do networking and block the
   whole session

 - shared state ("everything is global")
   - usability: huge buffer lists result in requiring window-manager
     like capabilities
   - configuration: a common look of the GUI
   - stability: one misbehaving program can blow up the whole session
   - task parallelism: most programs are intended to have only one
     running instance per session (ex.: a gnus for work, one for private
     mail; debugging with several instances of gud simultaneously)
   - security: I want my email client to know my IMAP password, but not
     my IRC client

 - auxiliary tasks
   tasks that are already solved on the desktop are duplicated, such as
   window and workspace management

One could say that Emacs doesn't do enough and solve these problems
"inside Emacs" by implementing concurrency, integrating firefox and
essentially becoming the desktop environment.

Or one could say that Emacs already does too much. The core features
could be factored out into a "text editing daemon". Elisp programs could
then connect to this daemon and share as much of their state with the
daemon as makes sense to them. Basically take the current
emacs-server/emacsclient situation a step further and transform the
client from a very thin client into a runtime.

I'm curious to see what emacs.devel is planning for Emacs25, now that 24
is finally released I think we can expect to see some action on
implementing new features. The two approaches are rather complementary
than exclusive; let's hope that both get some love.


[1] http://www.vimgolf.com/
[2] http://vimeo.com/timvisher/videos/page:1/sort:newest
[3] 
http://www.masteringemacs.org/articles/2011/10/29/fun-with-vimgolf-1-alphabetize-directory/
[4] http://www.faqs.org/docs/artu/ch01s06.html
[5] http://www.catb.org/~esr/writings/taoup/html/ch13s02.html
[6] http://www.catb.org/~esr/writings/taoup/html/ch13s03.html#id2967765

-- 
Philipp Haselwarter