From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.devel Subject: Re: Emacs learning curve Date: Thu, 22 Jul 2010 15:03:39 +0200 Message-ID: <201007221503.39812.tassilo@member.fsf.org> References: <4C3B6A8A.80105@gmx.de> <201007221414.39227.tassilo@member.fsf.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1279803848 18536 80.91.229.12 (22 Jul 2010 13:04:08 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 22 Jul 2010 13:04:08 +0000 (UTC) Cc: Ivan Kanis , Chong Yidong , Miles Bader , Tom , emacs-devel@gnu.org To: Lennart Borgman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 22 15:04:06 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 1ObvRR-0006iN-Rp for ged-emacs-devel@m.gmane.org; Thu, 22 Jul 2010 15:04:05 +0200 Original-Received: from localhost ([127.0.0.1]:60251 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ObvRO-0002pO-7O for ged-emacs-devel@m.gmane.org; Thu, 22 Jul 2010 09:03:58 -0400 Original-Received: from [140.186.70.92] (port=33914 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ObvRF-0002nc-FZ for emacs-devel@gnu.org; Thu, 22 Jul 2010 09:03:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ObvR9-0007fV-CO for emacs-devel@gnu.org; Thu, 22 Jul 2010 09:03:44 -0400 Original-Received: from deliver.uni-koblenz.de ([141.26.64.15]:26885) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ObvR9-0007fE-57; Thu, 22 Jul 2010 09:03:43 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by deliver.uni-koblenz.de (Postfix) with ESMTP id EF0C2781D0DF; Thu, 22 Jul 2010 15:03:41 +0200 (CEST) Original-Received: from deliver.uni-koblenz.de ([127.0.0.1]) by localhost (deliver.uni-koblenz.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29463-02; Thu, 22 Jul 2010 15:03:40 +0200 (CEST) X-CHKRCPT: Envelopesender noch tassilo@member.fsf.org Original-Received: from thinkpad.localnet (tsdh.uni-koblenz.de [141.26.67.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTP id D9349781D0DE; Thu, 22 Jul 2010 15:03:40 +0200 (CEST) User-Agent: KMail/1.13.5 (Linux/2.6.35-rc5-git6; KDE/4.4.5; x86_64; ; ) In-Reply-To: X-Face: `TY6r/ws=N5uqO1E`M=Sups<}n%T[E^o_?MJj< =?iso-8859-1?q?O4j=265ljV6lU=7DcXU7oftH=26/x=5F=7EK=7B=26zv9=7D=0A=09sB?= =?iso-8859-1?q?=7D5/Ea=5BhU=7BCS=23=3F=3F0=3F=3Fn?=@sX+ft]?{(l?, mp"a`u 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:127634 Archived-At: On Thursday 22 July 2010 14:18:40 Lennart Borgman wrote: > > And we would need to define new guidelines for modes. These > > recommendations are also in conflict with CUA: > > > > ,----[ (info "(elisp)Major Mode Conventions") ] > > | * The key sequences bound in a major mode keymap should usually > > | start with `C-c', followed by a control character, a digit, or `{', > > | `}', `<', `>', `:' or `;'. The other punctuation characters are > > | reserved for minor modes, and ordinary letters are reserved for > > | users. > > `---- > > > > ,----[ (info "(elisp)Keymaps and Minor Modes") ] > > | The key sequences bound in a minor mode should consist of `C-c' > > | followed by one of `.,/?`'"[]\|~!#$%^&*()-_+='. (The other punctuation > > | characters are reserved for major modes.) > > `---- > > > > But since old emacs users and users happy with the emacs way would > > like to stick to the default bindings, we would have to somehow > > invend conventions that fit for both Emacs and CUAmacs. I'm pretty > > sure that's near to impossible if you want to preserve a rest of > > mnemonics and consistency. > > Aren't your description rather accurate also without making CUA mode > default? No. New users don't have configs they need to change, and existing modes already stick to these (non-CUA-friendly) conventions. > (Except for swapping new and old users?) I wanted to say, that making CUA default would involve replacing binding conventions and changing gazillions of bindings accordingly. > This is what I mean with that CUA mode currently is a second citizen. Well, that's true. But IMO it's impossible to have two first class keybinding schemes. Bye, Tassilo