From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Emacs terminology (not again!?) [was: Apologia for bzr] Date: Sat, 18 Jan 2014 12:32:46 +0100 Message-ID: <87mwitwmn5.fsf@fencepost.gnu.org> References: <877gact76s.fsf@gnu.org> <34c8c13b-c5c6-4e5a-9248-b09d5d1936da@default> <87eh4hkq6c.fsf@fencepost.gnu.org> <83y52dk82n.fsf@gnu.org> <87zjmtwqtv.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1390044770 16295 80.91.229.3 (18 Jan 2014 11:32:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 Jan 2014 11:32:50 +0000 (UTC) Cc: Emacs-Devel devel To: Lennart Borgman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 18 12:32:57 2014 Return-path: Envelope-to: ged-emacs-devel@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 1W4U90-00046f-Ta for ged-emacs-devel@m.gmane.org; Sat, 18 Jan 2014 12:32:55 +0100 Original-Received: from localhost ([::1]:42018 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4U90-0008Sk-G5 for ged-emacs-devel@m.gmane.org; Sat, 18 Jan 2014 06:32:54 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41694) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4U8x-0008Se-1B for emacs-devel@gnu.org; Sat, 18 Jan 2014 06:32:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W4U8t-0003NG-QG for emacs-devel@gnu.org; Sat, 18 Jan 2014 06:32:50 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:44415) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4U8t-0003NC-NE for emacs-devel@gnu.org; Sat, 18 Jan 2014 06:32:47 -0500 Original-Received: from localhost ([127.0.0.1]:51590 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4U8t-0004SD-1c; Sat, 18 Jan 2014 06:32:47 -0500 Original-Received: by lola (Postfix, from userid 1000) id 982D3E0507; Sat, 18 Jan 2014 12:32:46 +0100 (CET) In-Reply-To: (Lennart Borgman's message of "Sat, 18 Jan 2014 12:03:26 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:168667 Archived-At: Lennart Borgman writes: > On Sat, Jan 18, 2014 at 11:02 AM, David Kastrup wrote: > >> Lennart Borgman writes: >> > I guess that we are really discussing is if there is an advantage of >> > such a setup. In the light of that there was a whole new editor >> > (gedit) created I think there could have been a better route. Emacs >> > could probably have provided everything that gedit gives. >> > >> > I also guess it would have been less work. And there would have been a >> > larger community using and working on Emacs. >> >> The future of Emacs depends on people with an attention span and >> perseverence sufficient for extending it. Those are the people who are >> most likely to be annoyed at the inconsistency of concepts and >> operations of things like the full CUA mode (the one which uses >> heuristics to decide whether to use C-x and C-c in the Emacs or the CUA >> sense). > > Are you really sure you want to look down upon those that do not > agree? ;-) It's not a question on looking up or down. Let me quote from the CUA mode section in the Emacs manual: The command =E2=80=98M-x cua-mode=E2=80=99 sets up key bindings that ar= e compatible with the Common User Access (CUA) system used in many other applications. When CUA mode is enabled, the keys =E2=80=98C-x=E2=80=99, =E2=80=98C= -c=E2=80=99, =E2=80=98C-v=E2=80=99, and =E2=80=98C-z=E2=80=99 invoke commands that cut (kill), copy, paste (yank), and undo respectively. The =E2=80=98C-x=E2=80=99 and =E2=80=98C-c=E2=80=99 keys= perform cut and copy only if the region is active. Otherwise, they still act as prefix keys, so that standard Emacs commands like =E2=80=98C-x C-c=E2=80=99 still work. Not= e that this means the variable =E2=80=98mark-even-if-inactive=E2=80=99 has no effect for = =E2=80=98C-x=E2=80=99 and =E2=80=98C-c=E2=80=99 (*note Using Region::). To enter an Emacs command like =E2=80=98C-x C-f=E2=80=99 while the m= ark is active, use one of the following methods: either hold =E2=80=98Shift=E2=80=99 t= ogether with the prefix key, e.g., =E2=80=98S-C-x C-f=E2=80=99, or quickly type the pref= ix key twice, e.g., =E2=80=98C-x C-x C-f=E2=80=99. Now this is touted as a feature to make things _simple_ for people. In reality, _competent_ use of it requires _lots_ of learning and surprises. If I enable CUA mode and type C-h k C-x C-c, I read C-x C-c runs the command save-buffers-kill-terminal, which is an interactive compiled Lisp function in `files.el'. It is bound to C-x C-c, . (save-buffers-kill-terminal &optional ARG) Offer to save each buffer, then kill the current connection. If the current frame has no client, kill Emacs itself. With prefix ARG, silently save all file-visiting buffers, then kill. If emacsclient was started with a list of filenames to edit, then only these files will be asked to be saved. [back] But if there is an active region, C-h k C-x prints C-x runs the command cua--prefix-override-handler, which is an interactive compiled Lisp function in `cua-base.el'. It is bound to C-c, C-x. (cua--prefix-override-handler ARG) Start timer waiting for prefix key to be followed by another key. Repeating prefix key when region is active works as a single prefix key. [back] This kind of mode dependency is what Emacs proponents in the editor wars tend to describe as a disadvantage of vi. This kind of "do the expected thing" setup may delay the time until cursory Emacs users will hit a wall of learning. But when they do, the wall is higher. This puts a larger complexity gap between "simple users" and "power users or programmers" who actually can work their tool with confidence. I don't see that making Emacs fit the Gedit task space would have yielded a result where Gedmacs users would have grown into active participants of the Emacs universe. In the long run, we need to make sure that Emacs remains comprehensible to Emacs users. That does not preclude changing keybindings and concepts, but getting multiple concurrent warring keybindings and concepts sorted by various heuristics is not the way to simplicity. --=20 David Kastrup