* Codifications of rules (was Re: bug#5119: ruby-mode binds TAB)
@ 2009-12-07 19:55 Matthew Dempsky
2009-12-07 20:56 ` David Reitter
2009-12-07 21:37 ` Stefan Monnier
0 siblings, 2 replies; 9+ messages in thread
From: Matthew Dempsky @ 2009-12-07 19:55 UTC (permalink / raw)
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Codifications of rules (was Re: bug#5119: ruby-mode binds TAB) 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 2009-12-08 1:57 ` Codifications of rules Stefan Monnier 2009-12-07 21:37 ` Stefan Monnier 1 sibling, 2 replies; 9+ messages in thread From: David Reitter @ 2009-12-07 20:56 UTC (permalink / raw) To: Matthew Dempsky; +Cc: Emacs discussions [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Codifications of rules (was Re: bug#5119: ruby-mode binds TAB) 2009-12-07 20:56 ` David Reitter @ 2009-12-08 1:23 ` Stephen J. Turnbull 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 1 sibling, 2 replies; 9+ messages in thread From: Stephen J. Turnbull @ 2009-12-08 1:23 UTC (permalink / raw) To: Emacs discussions; +Cc: Matthew Dempsky 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Codifications of rules 2009-12-08 1:23 ` Stephen J. Turnbull @ 2009-12-08 2:03 ` Stefan Monnier 2009-12-08 5:00 ` Codifications of rules (was Re: bug#5119: ruby-mode binds TAB) David Reitter 1 sibling, 0 replies; 9+ messages in thread From: Stefan Monnier @ 2009-12-08 2:03 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Matthew Dempsky, Emacs discussions > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Codifications of rules (was Re: bug#5119: ruby-mode binds TAB) 2009-12-08 1:23 ` Stephen J. Turnbull 2009-12-08 2:03 ` Codifications of rules Stefan Monnier @ 2009-12-08 5:00 ` David Reitter 1 sibling, 0 replies; 9+ messages in thread From: David Reitter @ 2009-12-08 5:00 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Matthew Dempsky, Emacs discussions [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Codifications of rules 2009-12-07 20:56 ` David Reitter 2009-12-08 1:23 ` Stephen J. Turnbull @ 2009-12-08 1:57 ` Stefan Monnier 1 sibling, 0 replies; 9+ messages in thread From: Stefan Monnier @ 2009-12-08 1:57 UTC (permalink / raw) To: Emacs discussions; +Cc: Matthew Dempsky > - 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Codifications of rules 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-07 21:37 ` Stefan Monnier 2009-12-07 22:13 ` Matthew Dempsky 2009-12-08 0:03 ` Eric M. Ludlam 1 sibling, 2 replies; 9+ messages in thread From: Stefan Monnier @ 2009-12-07 21:37 UTC (permalink / raw) To: Matthew Dempsky; +Cc: emacs-devel >> 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Codifications of rules 2009-12-07 21:37 ` Stefan Monnier @ 2009-12-07 22:13 ` Matthew Dempsky 2009-12-08 0:03 ` Eric M. Ludlam 1 sibling, 0 replies; 9+ messages in thread From: Matthew Dempsky @ 2009-12-07 22:13 UTC (permalink / raw) To: emacs-devel 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. ;)) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Codifications of rules 2009-12-07 21:37 ` Stefan Monnier 2009-12-07 22:13 ` Matthew Dempsky @ 2009-12-08 0:03 ` Eric M. Ludlam 1 sibling, 0 replies; 9+ messages in thread From: Eric M. Ludlam @ 2009-12-08 0:03 UTC (permalink / raw) To: Stefan Monnier; +Cc: Matthew Dempsky, emacs-devel 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 > > > ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2009-12-08 5:00 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.