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

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

[Matthew Dempsky]

On Thu, Dec 3, 2009 at 7:36 PM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> It binds TAB to ruby-indent-line. That is against the rules. ;-)

Out of curiosity, are 'rules' like this codified anywhere?  As I've
started using Emacs seriously again, I've started noticing a lot of
little inconsistencies between extensions (e.g., how temporary windows
are displayed/destroyed).  I'd be happy to submit patches to help
improve this if someone could point out the correct behavior.

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

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 1776 bytes --]

On Dec 7, 2009, at 2:55 PM, Matthew Dempsky wrote:

> On Thu, Dec 3, 2009 at 7:36 PM, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>> It binds TAB to ruby-indent-line. That is against the rules. ;-)
> 
> Out of curiosity, are 'rules' like this codified anywhere?  As I've
> started using Emacs seriously again, I've started noticing a lot of
> little inconsistencies between extensions (e.g., how temporary windows
> are displayed/destroyed).  I'd be happy to submit patches to help
> improve this if someone could point out the correct behavior.

I'd like to know that, too.  There are many equivalent commands bound to different keys in different major modes.  My pet peeves are

- Indentation (left/right, e.g. C-c C-> in python-mode, as well as re-indenting the current line according to syntax)
- Deleting the content of a comint output buffer (e.g. C-c M-o in SLIME, but different elsewhere)
- 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.
- Running the inferior interpreter process.  M-x R in ESS, M-x slime in SLIME (rather than M-x lisp), and M-x run-python (rather than M-x python) in python-mode.

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.



See also:

http://www.opensubscriber.com/message/emacs-devel@gnu.org/3558580.html 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

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

[Stephen J. Turnbull]

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.

Re: Codifications of rules

[Stefan Monnier]

> 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.)

C-h f indent-region says it's bound to C-M-\
But actually C-u TAB works in a way more similar to Python's C-c >


        Stefan

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

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 1130 bytes --]

On Dec 7, 2009, at 8:23 PM, Stephen J. Turnbull wrote:

> 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.

> 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 

Sorry, perhaps I wasn't clear and my parenthesis doesn't help at all.  I didn't mean to imply that left/right movement (semantics-changing in Python) should be equivalent to re-indenting semi-automatically (as done with TAB). 

My take-home message is that not enough such functions can be rebound centrally.  I'd like to have A-] to shift to the right, for instance, no matter what the mode is.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: Codifications of rules

[Stefan Monnier]

> - 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.

This does indeed point to one missing functionality:
an "inferior-comint-minor-mode".  I.e. a minor to use in source code
buffers that provides the usual bindings to send commands to some
underlying comint buffer (like C-c C-l).

> - Running the inferior interpreter process.  M-x R in ESS, M-x slime
> in SLIME (rather than M-x lisp), and M-x run-python (rather than M-x
> python) in python-mode.

M-x run-<foo> is the standard name used.  I don't love it because it
breaks the "prefix all functions" convention, but it's been around for
a long time.


        Stefan

Re: Codifications of rules

[Stefan Monnier]

>> It binds TAB to ruby-indent-line. That is against the rules. ;-)
> Out of curiosity, are 'rules' like this codified anywhere?

Not much, sadly.  There Elisp manual has a section about coventions to
follow for major modes, so the info should be there, but there's a lot
more conventions than the documented ones.

But as a general rule, if you want key K to do something it's preferable
to do it by setting some variables that affect K's default binding than
by rebinding it to another command.

I.e. better set indent-line-function, fill-paragraph-function,
completion-at-point-functions, rather than rebing TAB, M-q , M-TAB, ...

The general goal should be to make it easier for a user to state
global preferences that affect all modes.

> As I've started using Emacs seriously again, I've started noticing
> a lot of little inconsistencies between extensions (e.g., how
> temporary windows are displayed/destroyed).  I'd be happy to submit
> patches to help improve this if someone could point out the
> correct behavior.

These are usually welcome here (although they also tend to be delicate
because users get quickly used to the old behavior and then show
resistance to change).


        Stefan

Re: Codifications of rules

[Matthew Dempsky]

On Mon, Dec 7, 2009 at 1:37 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> Not much, sadly.  There Elisp manual has a section about coventions to
> follow for major modes, so the info should be there, but there's a lot
> more conventions than the documented ones.

Yeah, that's my impression.  I'm certainly a fan of consistency, so if
anyone else would find it useful, I'm willing to volunteer to help
maintain some documentation on standard coding conventions for Emacs
extensions.

> The general goal should be to make it easier for a user to state
> global preferences that affect all modes.

Agreed.

> These are usually welcome here (although they also tend to be delicate
> because users get quickly used to the old behavior and then show
> resistance to change).

Understood.

I'm happy to start reporting bugs about inconsistent behaviors so we
can discuss how to resolve them or whether they're better left as they
are.  I just don't want to distract developers from more important
issues.  (Satisfying my OCD is certainly important to me, but perhaps
not so much others. ;))

Re: Codifications of rules

[Eric M. Ludlam]

Hi,

The mode-local tool that came in with the CEDET stuff has a notion of 
"mode local" functions.  A tool maintainer will mark a function as being 
overloadable, and a major-mode author defines the same function as 
overloaded for a particular mode.

In this way a tool (like Semantic) can define a bunch of core feature 
function APIs, and major modes can easily define that custom behavior. 
Functions like beginning/end of defun have ways to override with special 
variables.  Mode local does something similar, but the macros allow 
codification of rules.  For example, it ensures the doc-string specifies 
it can be overloaded.  If additional "rules" are needed to help, they 
could be added to the macros.

Some of the things listed in the thread so far would be easily handled 
by mode-local.

Eric

Stefan Monnier wrote:
>>> It binds TAB to ruby-indent-line. That is against the rules. ;-)
>> Out of curiosity, are 'rules' like this codified anywhere?
> 
> Not much, sadly.  There Elisp manual has a section about coventions to
> follow for major modes, so the info should be there, but there's a lot
> more conventions than the documented ones.
> 
> But as a general rule, if you want key K to do something it's preferable
> to do it by setting some variables that affect K's default binding than
> by rebinding it to another command.
> 
> I.e. better set indent-line-function, fill-paragraph-function,
> completion-at-point-functions, rather than rebing TAB, M-q , M-TAB, ...
> 
> The general goal should be to make it easier for a user to state
> global preferences that affect all modes.
> 
>> As I've started using Emacs seriously again, I've started noticing
>> a lot of little inconsistencies between extensions (e.g., how
>> temporary windows are displayed/destroyed).  I'd be happy to submit
>> patches to help improve this if someone could point out the
>> correct behavior.
> 
> These are usually welcome here (although they also tend to be delicate
> because users get quickly used to the old behavior and then show
> resistance to change).
> 
> 
>         Stefan
> 
> 
>