From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philipp Haselwarter Newsgroups: gmane.emacs.help Subject: Re: Emacs users a dying breed? Date: Tue, 19 Jun 2012 16:03:20 +0200 Message-ID: <87lijj9z6f.fsf@nzebook.haselwarter.org> References: <87aa00wkrd.fsf@jidanni.org> <000c01cd4d83$adcde9a0$0969bce0$@rogers.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1340114640 13602 80.91.229.3 (19 Jun 2012 14:04:00 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 19 Jun 2012 14:04:00 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Jun 19 16:03:57 2012 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Sgz2C-0007GH-41 for geh-help-gnu-emacs@m.gmane.org; Tue, 19 Jun 2012 16:03:56 +0200 Original-Received: from localhost ([::1]:39399 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sgz2C-0007DQ-1z for geh-help-gnu-emacs@m.gmane.org; Tue, 19 Jun 2012 10:03:56 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:41643) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sgz21-0007D0-Dj for help-gnu-emacs@gnu.org; Tue, 19 Jun 2012 10:03:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sgz1v-0000H3-3q for help-gnu-emacs@gnu.org; Tue, 19 Jun 2012 10:03:44 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:57843) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sgz1u-0000Gt-Pv for help-gnu-emacs@gnu.org; Tue, 19 Jun 2012 10:03:39 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Sgz1q-0006NH-Ek for help-gnu-emacs@gnu.org; Tue, 19 Jun 2012 16:03:34 +0200 Original-Received: from 130.116.113.78.rev.sfr.net ([78.113.116.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Jun 2012 16:03:34 +0200 Original-Received: from philipp by 130.116.113.78.rev.sfr.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Jun 2012 16:03:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 101 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 130.116.113.78.rev.sfr.net User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.1.50 (gnu/linux) X-NSA-Fodder: cracking Semtex militia sweep SSL constitution propaganda Cancel-Lock: sha1:67PbiAjUP0XNAheW405cB2cMo8I= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:85305 Archived-At: 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