From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Tweaking t-m-m to make room for d-s-m Date: Fri, 26 Mar 2010 15:13:53 -0700 Message-ID: References: <87sk7pzqsp.fsf@ambire.localdomain> <8739zps45s.fsf@mean.albasani.net> <87mxxw6c7b.fsf@lola.goethe.zz> <20100326092833.19294vuz9efv5qg4@webmail.mnet-online.de> <33DBCF2DFF71401DB0861E66EC29ED2B@us.oracle.com> <5F1D87251C98412EADC1187ABFCC3E8D@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1269641720 19126 80.91.229.12 (26 Mar 2010 22:15:20 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 26 Mar 2010 22:15:20 +0000 (UTC) Cc: mathias@mnet-mail.de, 'David Kastrup' , 'Stefan Monnier' , emacs-devel@gnu.org To: "'Lennart Borgman'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 26 23:15:15 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1NvHo9-0003qJ-64 for ged-emacs-devel@m.gmane.org; Fri, 26 Mar 2010 23:15:13 +0100 Original-Received: from localhost ([127.0.0.1]:45518 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NvHo8-0006wm-GY for ged-emacs-devel@m.gmane.org; Fri, 26 Mar 2010 18:15:12 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NvHnz-0006w8-D7 for emacs-devel@gnu.org; Fri, 26 Mar 2010 18:15:03 -0400 Original-Received: from [140.186.70.92] (port=57000 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NvHnx-0006vc-F2 for emacs-devel@gnu.org; Fri, 26 Mar 2010 18:15:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NvHni-0007vv-IP for emacs-devel@gnu.org; Fri, 26 Mar 2010 18:14:48 -0400 Original-Received: from rcsinet11.oracle.com ([148.87.113.123]:29413) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NvHni-0007vq-B6; Fri, 26 Mar 2010 18:14:46 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o2QMEgVo012867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 26 Mar 2010 22:14:44 GMT Original-Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o2QJ9LIp019712; Fri, 26 Mar 2010 22:14:39 GMT Original-Received: from abhmt018.oracle.com by acsmt353.oracle.com with ESMTP id 120804421269641634; Fri, 26 Mar 2010 15:13:54 -0700 Original-Received: from dradamslap1 (/141.144.73.76) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 26 Mar 2010 15:13:54 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcrNK6bYrURIyEyWQIWuNFOoqO1cpgAAImxQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4BAD31D2.0045:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:122732 Archived-At: > >> > C-z > >> > >> I think that would be a very bad idea since C-z seems to be used as > >> undo in most editing environments. > > > > And C-z is currently `suspend-frame' in Emacs. > > And you have said this is not an important use since there are > alternative key bindings. Yes, I mentioned that there is another default binding, C-x C-z. Either C-z or C-x C-z could be used as the activate/deactivate region toggle. The former is simpler. Hitting C-z is as easy as hitting C-g (what we do today to deactivate). (Oh - is C-z undo in CUA? Is C-g cancel in Emacs? Hm. Is that a somewhat happy coincidence? Inquiring minds do not want to know.) > > CUA is so very different from Emacs that I see no need to > > consider such conflicts. Emacs does not sync with CUA's > > C-c, C-x, C-v, ESC,... Why should we > > treat CUA's C-z with special respect? > > It is new users that should be treated with respect. All of them know > these key bindings. All of them use them. (If they are not computer > illiterates.) Treating new users with respect means helping them learn the best ways to be productive with Emacs. I happen to think that includes d-s-mode but not cua-mode. We can respectfully agree to disagree about that. But please do not think you have a monopoly on respect for new users. Sometimes respect means advising against what someone feels comfortable with. Call it tough love. ;-) > > Arguments that Emacs should do something by default _only_ > > because vi (e.g. Viper) or CUA does it are non-starters, with > > me at least. > > The vim community has accepted them. To me that means that they (as a > community) have accepted that they are important. Yes, and so have some GNU/Linux GUIs accepted them, and lots of other applications - most even. You are no doubt correct in saying that Emacs stands pretty much alone in not adopting CUA (or similar). (There are some non-Emacs applications that have accepted Emacs's main editing keys. But that is beside the point.) > Emacs has not accepted them. I fairly certain the problem is backward > compatibility in Emacs. Nothing else at all. (Of course backward > compatibility is important but it is not the whole story.) Since you use Viper, it is understandable that you would get that an alternative set of bindings for Emacs is possible. Can't argue with that. It is possible. But I'm not convinced that the only rationale for the current Emacs bindings is the sorry weight of legacy. > But I do not expect CUA keys to be accepted now, I just want to avoid > adding new troubles. Using C-z for something new (except `undo') would > be new trouble IMO. Why? Isn't it just as troublesome that C-z means `resume-frame'? The trouble you would fend off is already here, I fear. It is too late to reserve C-z for possible future CUA use. Someone got to C-z before you (on Day One). And if one day Emacs does become CUA by default, do you really think changing C-z from activate/deactivate the mark to `cut' will be the most difficult part? > > But Emacs's use of keyboard keys blows the "half-dozen > > editing operations" scenario out of the water. > > I would rather say it looks like CUA blows Emacs out of the water ;-) I was referring to the large number of keyboard keys that Emacs uses on a daily basis. When you have only a few operations to bind, it's easy to give them the keys that are the handiest to type. > But that is not what I want. > > > AFAICS, the _only_ reason for Emacs to conform to CUA > > would be to have a better fit with the outside world. For > > me, that is not a sufficient reason. > > If you just say "conform" you may miss the essentials of it. It is > about user convenience, not about some strictness called "conform" or > "better fit". You used the word "accept" (above). Accept/conform/fit/kowtow/appease/support - pick whatever term you like. It is about user convenience in _using Emacs_, not just about user convenience in getting comfortable just being in the same room with Emacs. It's not only about cozying up to newbies. It's about helping them to become productive Emacs users. I, for one, am not convinced that CUA or Viper is the best way to promote Emacs productivity. But my sample data is small. Just one opinion.