From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Codifications of rules (was Re: bug#5119: ruby-mode binds TAB) Date: Tue, 08 Dec 2009 10:23:07 +0900 Message-ID: <873a3mtg1w.fsf@uwakimon.sk.tsukuba.ac.jp> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1260235154 12963 80.91.229.12 (8 Dec 2009 01:19:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Dec 2009 01:19:14 +0000 (UTC) Cc: Matthew Dempsky To: Emacs discussions Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 08 02:19:06 2009 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.50) id 1NHojJ-0001ML-Oe for ged-emacs-devel@m.gmane.org; Tue, 08 Dec 2009 02:19:06 +0100 Original-Received: from localhost ([127.0.0.1]:35166 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NHojJ-0001Xy-CX for ged-emacs-devel@m.gmane.org; Mon, 07 Dec 2009 20:19:05 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NHojD-0001WE-M4 for emacs-devel@gnu.org; Mon, 07 Dec 2009 20:18:59 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NHoj9-0001Uq-2l for emacs-devel@gnu.org; Mon, 07 Dec 2009 20:18:59 -0500 Original-Received: from [199.232.76.173] (port=37010 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NHoj8-0001Un-T4 for emacs-devel@gnu.org; Mon, 07 Dec 2009 20:18:54 -0500 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:49763) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NHoj8-0005Sq-9J for emacs-devel@gnu.org; Mon, 07 Dec 2009 20:18:54 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id C216C7FFA; Tue, 8 Dec 2009 10:18:49 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 7ABE31200C4; Tue, 8 Dec 2009 10:23:07 +0900 (JST) In-Reply-To: X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" 1444e28f1a3d XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:118378 Archived-At: David Reitter writes: > [Pet peeves:] > - Indentation (left/right, e.g. C-c C-> in python-mode, as well as > re-indenting the current line according to syntax) Indentation in Python changes the semantics of the code, and it cannot be deduced from the syntax of the code in the buffer. This is not true for other languages, and it's not surprising to me that Pythonistas want an indentation function that works according to current level *and* one that changes level. > - Executing / evaluating a line or an expression or a region with > the inferior process, e.g. C-x C-e in Elisp and in SLIME's > lisp-mode, but C-j (for the line) in R-mode (ESS). Then, SLIME > and Python-mode have C-c C-r to evaluate the region, but > emacs-lisp-mode doesn't have that. C-x C-e and C-j have rather different semantics in Lisp Interaction mode (I don't know about SLIME): C-x C-e displays the value in the echo area, while C-j inserts it in the interaction buffer. And I'm not really sure what the usefulness of evaluating a region is in Lisp, while in Python it's a fairly natural way to specify a suite (compound statement) to the interpreter, and is necessary to specify a sub-expression. These examples show that it's going to be hard to come up with a reasonably concise list of such functionality. > Generally, the point here would not be to just define canonical > bindings for these functions, but define more canonical > buffer-local variables that contain appropriate function names, > such as the existing `indent-line-function', so that the user (or > we) can bind whatever standard keys to the appropriate commands. I'm sorry, but I can't make sense of this proposal. The authors of these modes (as evidenced above) typically feel that the (Emacs) semantics they are trying to express is *different* from that bound to the "standard" key. Eg, in Python mode TAB *is* bound to indent-for-tab-command and it *does* do the right thing. C-c > is *additional* functionality (although perhaps it should be expressed via a modification of `indent-region', but `indent-region' is not bound to a key AFAICS.) There are places where modes deliberately vary. For example, some Python modes bind RET instead of C-j to the "execute line" function. I think this is bad for Emacs, no matter how natural the mode author thinks it is for her application. But the common case is that the mode author differentiates mode behavior more finely than "standard Emacs" does, and therefore needs additional bindings.