unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Stephen J. Turnbull" <stephen@xemacs.org>
To: Emacs discussions <emacs-devel@gnu.org>
Cc: Matthew Dempsky <matthew@dempsky.org>
Subject: Re: Codifications of rules (was Re: bug#5119: ruby-mode binds TAB)
Date: Tue, 08 Dec 2009 10:23:07 +0900	[thread overview]
Message-ID: <873a3mtg1w.fsf@uwakimon.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <C97ECBDF-941B-48C5-91AE-9A2BB9AA70B9@gmail.com>

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.




  reply	other threads:[~2009-12-08  1:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-07 19:55 Codifications of rules (was Re: bug#5119: ruby-mode binds TAB) Matthew Dempsky
2009-12-07 20:56 ` David Reitter
2009-12-08  1:23   ` Stephen J. Turnbull [this message]
2009-12-08  2:03     ` Codifications of rules Stefan Monnier
2009-12-08  5:00     ` Codifications of rules (was Re: bug#5119: ruby-mode binds TAB) David Reitter
2009-12-08  1:57   ` Codifications of rules Stefan Monnier
2009-12-07 21:37 ` Stefan Monnier
2009-12-07 22:13   ` Matthew Dempsky
2009-12-08  0:03   ` Eric M. Ludlam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=873a3mtg1w.fsf@uwakimon.sk.tsukuba.ac.jp \
    --to=stephen@xemacs.org \
    --cc=emacs-devel@gnu.org \
    --cc=matthew@dempsky.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).