emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Codifications of rules (was Re: bug#5119: ruby-mode binds TAB)


From: Stephen J. Turnbull
Subject: Re: Codifications of rules (was Re: bug#5119: ruby-mode binds TAB)
Date: Tue, 08 Dec 2009 10:23:07 +0900

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 via email to

[Prev in Thread] Current Thread [Next in Thread]