emacs-devel
[Top][All Lists]
Advanced

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

Re: Specifying mode in file variables trouble


From: Lennart Borgman (gmail)
Subject: Re: Specifying mode in file variables trouble
Date: Mon, 22 Sep 2008 15:14:13 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666

Richard M. Stallman wrote:
>     Maybe, but I think most oftenly that will create name clashes.
> 
> It will cause name clashes is you choose names of existing major modes,
> but you can easily avoid using those.
> 
> Here's what I suggest:
> 
> If there is a customary name (say, `foo' for a kind of file which mixes
> a few ordinary major modes, call the command `foo-mode'.
> 
> Otherwise, if you want a command for the combination of two modes `a'
> and `b', call it `a-b-mode'.
> 
> Or we could use `a+b-mode' for such cases.

I like the idea of using "+" here, that is a good mnemonic.

For web template files (like PHP, JSP, Genshi etc) there are however
often several major mode chunks involved. In for example a php file
there may be chunks with these major modes

  - nxhtml-mode / html-mode
  - php-mode
  - css-mode
  - javascript-mode

I currently use the name nxhtml-mumamo-mode (or html-mumamo-mode) for
the multi major mode, which is of course not that very descriptive. The
name begins with "nxhtml-" because that is the main major mode (there
are only two levels allowed sofar, main major mode and sub chunks major
modes).

Along with your suggestion nxhtml+php-mode would be the most natural.
This name does not tell the whole truth, but is perhaps still less
cryptic than nxhtml-mumamo-mode. I am not quite sure.

>     (There are still good reasons to tell
>     that it is a multi major mode. The most difficult thing is support of
>     minor modes turn on/off and finding reasonable structures for that. Time
>     will tell I think.)
> 
> Let's talk about this problem; maybe I can suggest a general solution
> for it.

There might be several problem, but the bug report I just recieved for
Imenu illustrates one principal problem:

  https://bugs.launchpad.net/bugs/272526

I have not looked into the details, but the problem reports says that
Imenu does not work as expected when moving between chunks (with
different major modes).

The principal problem here is probably that Imenu should work across all
chunks with the same major modes and preserve its chunk specifric values
when moving between those chunks.

So I am thinking about saving those values in a variable, something like
this

  (make-variable-buffer-local 'mumamo-survive-minor-modes)
  (put 'mumamo-survive-minor-modes 'permanent-local t)
  (defvar mumamo-survive-minor-modes nil
    "Hold local minor mode variables specific major modes.
  Those values are saved when leaving a chunk with a certain
  major mode and restored when entering a chunk with the same
  major mode again.

  The value of this variable is an associative list where the key
  is a list with

    \(MAJOR-MODE MINOR-MODE)

  and the value is a stored value for the minor mode.")

For storing the values I am thinking about using the code that does
something similar for visual-line-mode where state variable values are
stored in visual-line--saved-state.

However the drawback is that this has to be implemented for every minor
mode of this kind, but I can't see any way around it currently.

... eh, maybe another way to do it could be to save all buffer local
variables this way and make exceptions for some ...




reply via email to

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