emacs-devel
[Top][All Lists]
Advanced

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

Re: Codifications of rules


From: Eric M. Ludlam
Subject: Re: Codifications of rules
Date: Mon, 07 Dec 2009 19:03:17 -0500
User-agent: Thunderbird 2.0.0.23 (X11/20090817)

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







reply via email to

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