Specifying mode in file variables trouble

Specifying mode in file variables trouble

[Lennart Borgman (gmail)]

I got a question about specifying a multi major mode in a file like this

  <?php // -*- mode: nxhtml-mumamo -*-

This fails with

  Ignoring unknown mode `nxhtml-mumamo-mode'

Could we please compensate for this optimization ... ;-)

In other words: Emacs adds "-mode". That is frustrating, but can of
course not be changed. However if Emacs finds that this fails, can it
then check for just the given "symbol"?

That would allow the example above to work, and it would also help all
users that fail to notice this little twist in the manual. (I know I was
hit by this myself when I tried setting the mode this way.)

Re: Specifying mode in file variables trouble

[Lennart Borgman (gmail)]

Lennart Borgman (gmail) wrote:
> I got a question about specifying a multi major mode in a file like this
> 
>   <?php // -*- mode: nxhtml-mumamo -*-
> 
> This fails with
> 
>   Ignoring unknown mode `nxhtml-mumamo-mode'
> 
> Could we please compensate for this optimization ... ;-)
> 
> In other words: Emacs adds "-mode". That is frustrating, but can of
> course not be changed. However if Emacs finds that this fails, can it
> then check for just the given "symbol"?
> 
> That would allow the example above to work, and it would also help all
> users that fail to notice this little twist in the manual. (I know I was
> hit by this myself when I tried setting the mode this way.)

Forgot to add a link to the question I recieved:

  https://answers.launchpad.net/nxhtml/+question/45721

Re: Specifying mode in file variables trouble

[Miles Bader]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>   Ignoring unknown mode `nxhtml-mumamo-mode'
>
> Could we please compensate for this optimization ... ;-)

Of course, it would be much simpler just to add a `nxhtml-mumamo-mode'
alias, which would also have the benefit of making nxhtml-mumamo mode
more consistent with the rest of emacs.

-Miles

-- 
Cabbage, n. A familiar kitchen-garden vegetable about as large and wise as a
man's head.

Re: Specifying mode in file variables trouble

[Lennart Borgman (gmail)]

Miles Bader wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>>   Ignoring unknown mode `nxhtml-mumamo-mode'
>>
>> Could we please compensate for this optimization ... ;-)
> 
> Of course, it would be much simpler just to add a `nxhtml-mumamo-mode'
> alias, which would also have the benefit of making nxhtml-mumamo mode
> more consistent with the rest of emacs.

Hi Miles,

But it is not a major mode, that is why it does not end in "-mode". It
ends in "-mumamo" which stands for "multi major mode" here.

Maybe it should still end in "-mode", but I think it could be more
confusing than helping actually.

Beside that it does not help in the second case above.

Re: Specifying mode in file variables trouble

[Richard M. Stallman]

    But it is not a major mode, that is why it does not end in "-mode". It
    ends in "-mumamo" which stands for "multi major mode" here.

    Maybe it should still end in "-mode", but I think it could be more
    confusing than helping actually.

Why do you think it is not a major mode?  A major mode is simply a
command that specifies the overall way to handle the contents of a
buffer.  I think this command qualifies.

So its name should end in `-mode'.

Re: Specifying mode in file variables trouble

[Lennart Borgman (gmail)]

Richard M. Stallman wrote:
>     But it is not a major mode, that is why it does not end in "-mode". It
>     ends in "-mumamo" which stands for "multi major mode" here.
> 
>     Maybe it should still end in "-mode", but I think it could be more
>     confusing than helping actually.
> 
> Why do you think it is not a major mode?  A major mode is simply a
> command that specifies the overall way to handle the contents of a
> buffer.  I think this command qualifies.
> 
> So its name should end in `-mode'.

Ok, I am convinced. I have changed the name convention so that multi
major modes now ends in "-mumamo-mode" (instead of the old "-mumamo").

Re: Specifying mode in file variables trouble

[Richard M. Stallman]

    Ok, I am convinced. I have changed the name convention so that multi
    major modes now ends in "-mumamo-mode" (instead of the old "-mumamo").

That is good.  However, I would like to suggest that in some cases
there is no need to put `-mumamo' in these names.  If this is the
right mode for a certain language or type of file, known as FOO,
then this command should be called FOO-mode.

Re: Specifying mode in file variables trouble

[Lennart Borgman (gmail)]

Richard M. Stallman wrote:
>     Ok, I am convinced. I have changed the name convention so that multi
>     major modes now ends in "-mumamo-mode" (instead of the old "-mumamo").
> 
> That is good.  However, I would like to suggest that in some cases
> there is no need to put `-mumamo' in these names.  If this is the
> right mode for a certain language or type of file, known as FOO,
> then this command should be called FOO-mode.

Maybe, but I think most oftenly that will create name clashes. I think
that using "-mumamo-mode" is a good way to prevent this and also to tell
that it is a multi major modes. (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.)

Re: Specifying mode in file variables trouble

[Richard M. Stallman]

    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.

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

Re: Specifying mode in file variables trouble

[Lennart Borgman (gmail)]

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

Re: Specifying mode in file variables trouble

[Stefan Monnier]

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

Why not web-template-mode?


        Stefan

Re: Specifying mode in file variables trouble

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
>> 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).
> 
> Why not web-template-mode?


There are many kind of web templates, for example

  smarty
  genshi
  embperl
  eruby
  mako
  php
  django
  mjt
  jsp
  noweb
  ...

For each of them I have one with html-mode as main mode and one with
nxhtml-mode as main mode.

Re: Specifying mode in file variables trouble

[Richard M. Stallman]

    For each of them I have one with html-mode as main mode and one with
    nxhtml-mode as main mode.

Why is it necessary to have both?

Re: Specifying mode in file variables trouble

[Lennart Borgman (gmail)]

Richard M. Stallman wrote:
>     For each of them I have one with html-mode as main mode and one with
>     nxhtml-mode as main mode.
> 
> Why is it necessary to have both?

There are currently to different major modes for handling XHTML files in
Emacs:

html-mode: This is based on sgml-mode. This is a "normal" major mode
where everything works ok with MuMaMo.

nxml-mode: This is James Clark's nXml mode which has DTD based
validation and completion for XML files. (DTD=Document Type Definition,
this describes what XML tags and attributes are allowed and where etc.)

nxhtml-mode is based on nxml-mode. I have added some more convenient
completion functions for XHTML files there. This is not part of Emacs. I
distribute it in the nXhtml package together with MuMaMo.

There are still some problems with the nxml-mode parser and multi major
modes. Most of the time it works well, but it is not perfect.


So there are two reasons:

- html-mode is included in Emacs, but nxhtml-mode is not.
- html-mode works ok with multi major modes, while there are some minor
(from a users perspective) glitches with how nxhtml-mode works with
multi major modes.

Re: Specifying mode in file variables trouble

[Richard M. Stallman]

    nxhtml-mode is based on nxml-mode. I have added some more convenient
    completion functions for XHTML files there. This is not part of Emacs. I
    distribute it in the nXhtml package together with MuMaMo.

When we install MuMaMo, I guess we can install this too.

Re: Specifying mode in file variables trouble

[Lennart Borgman (gmail)]

Lennart Borgman (gmail) wrote:
> 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 ...


Here is something along the line of the last idea just above here:

(defun mumamo-save-buffer-locals (major)
  "Save some local variables for major mode MAJOR.
This should be called before switching to a new chunks major
mode."
  (let ((locals (buffer-local-variables)))
    (setq locals (mapcar (lambda (local)
                           (unless (or
                                    (memq (car local)
mumamo-buffer-locals-dont-set)
                                    (memq (car local) mumamo-survive)
                                    (get (car local) 'permanent-local)
                                    )))
                         locals))
    (setq locals (delq nil locals))
    (setq mumamo-buffer-locals-per-major
          (assq-delete-all major mumamo-buffer-locals-per-major))
    (setq mumamo-buffer-locals-per-major
          (cons (cons major-mode locals)
                mumamo-buffer-locals-per-major))))

;; (benchmark 1000 '(mumamo-save-buffer-locals major-mode))
;; (benchmark 1000 '(mumamo-restore-buffer-locals major-mode))
(defun mumamo-restore-buffer-locals (major)
  "Restore some local variables for major mode MAJOR.
This should be called after switching to a new chunks major
mode."
  (let ((locals (cdr (assq major mumamo-buffer-locals-per-major)))
        var
        perm)
    (dolist (rec locals)
      (setq var (car rec))
      (setq perm (get var 'permanent-local))
      (unless (or perm
                  (memq var mumamo-buffer-locals-dont-set))
        (setq var (cdr rec))))))

Re: Specifying mode in file variables trouble

[Richard M. Stallman]

    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

It seems to me that if PHP files are likely to contain these other
things, it is good for Emacs to handle them automatically in PHP files.

Here's one way: rename the basic PHP mode to `php-only-mode', and
define `php-mode' as the mumamo mode to handle all of these.  What do
you think?

Another variant is to make `php-mode' check for other languages, and
call either `php-only-mode' or `php-mumamo-mode'.  Or perhaps it could
select among a larger variety of modes, depending on what combinations
of languages are actually used in one file.

If we don't do this, users can cope by adding explicit -*- specs.  But
that is inconvenient, so why not do this automatically?

Re: Specifying mode in file variables trouble

[Lennart Borgman (gmail)]

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

Richard M. Stallman wrote:
>     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
> 
> It seems to me that if PHP files are likely to contain these other
> things, it is good for Emacs to handle them automatically in PHP files.

Yes, I agree.

> Here's one way: rename the basic PHP mode to `php-only-mode', and
> define `php-mode' as the mumamo mode to handle all of these.  What do
> you think?

I am not sure. I liked html+php-mode better.

Maybe using the name php-mode would also create confusion since the name
is already in use. However php-only-mode may be a good choice.

BTW, php-mode.el (or some version of it) is still not in Emacs. I am
distributing it as part of nXhtml (and it can also be found on Emacs Wiki).

> Another variant is to make `php-mode' check for other languages, and
> call either `php-only-mode' or `php-mumamo-mode'.  Or perhaps it could
> select among a larger variety of modes, depending on what combinations
> of languages are actually used in one file.
> 
> If we don't do this, users can cope by adding explicit -*- specs.  But
> that is inconvenient, so why not do this automatically?

I have suggested a different solution to this quite general problem. I
think a list of major mode priorities would be better. I have
implemented that in majmodpri.el which I am resending here. (I think I
might have made some changes since last time I sent it.)


[-- Attachment #2: majmodpri.el --]
[-- Type: text/plain, Size: 10746 bytes --]

;;; majmodpri.el --- Major mode priorities handling
;;
;; Author: Lennart Borgman (lennart O borgman A gmail O com)
;; Created: 2008-08-26
(defconst majmodpri:version "0.6") ;;Version:
;; Last-Updated: 2008-08-26T19:21:00+0200 Tue
;; URL:
;; Keywords:
;; Compatibility:
;;
;; Features that might be required by this library:
;;
;;   None
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Commentary:
;;
;; Different elisp libraries may try to handle the same type of files.
;; They normally do that by entering their major mode for a file type
;; in `auto-mode-alist' or the other lists affecting `normal-mode'.
;; Since the libraries may be loaded in different orders in different
;; Emacs sessions this can lead to rather stochastic choices of major
;; mode.
;;
;; This library tries to give the control of which major modes will be
;; used back to the user.  It does that by letting the user set up
;; priorities among the major modes.  This priorities are used to sort
;; the lists used by `normal-mode'.
;;
;; To setup this libray and get more information do
;;
;;   M-x customize-group RET majmodpri RET
;;
;; Or, see the commands `majmodpri-sort-lists'.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Change log:
;;
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; This program is free software; you can redistribute it and/or
;; modify it under the terms of the GNU General Public License as
;; published by the Free Software Foundation; either version 2, or
;; (at your option) any later version.
;;
;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
;; General Public License for more details.
;;
;; You should have received a copy of the GNU General Public License
;; along with this program; see the file COPYING.  If not, write to
;; the Free Software Foundation, Inc., 51 Franklin Street, Fifth
;; Floor, Boston, MA 02110-1301, USA.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Code:


;;;; Idle sorting

(defvar majmodpri-idle-sort-timer nil)

(defun majmodpri-cancel-idle-sort ()
  "Cancel idle sorting request."
  (when majmodpri-idle-sort-timer
    (cancel-timer majmodpri-idle-sort-timer)
    (setq majmodpri-idle-sort-timer nil)))

(defun majmodpri-start-idle-sort ()
  "Request idle sorting."
  (majmodpri-cancel-idle-sort)
  (setq majmodpri-idle-sort-timer
        (run-with-idle-timer 0 nil 'majmodpri-sort-lists-in-timer)))

(defun majmodpri-sort-lists-in-timer ()
  (condition-case err
      (majmodpri-sort-lists)
    (error (message "(majmodpri-sort-lists): %s" err))))

;;;; Custom

(defgroup majmodpri nil
  "Customization group for majmodpri.el"
  :group 'nxhml
  )

(defcustom majmodpri-sort-after-load
  nil
  "Sort major mode lists after loading elisp libraries.
Sorting is not done immediately.  Instead it runs in an idle
timer.  This means that if several elisp libraries are loaded in
a command then the sorting will only be done once, after the
command has finished.

See `majmodpri-sort-lists' for more information."
  :type '(choice (const :tag "Never" nil)
                 (const :tag "After loading any elisp library" t)
                 (repeat :tag "After loading specified libraries" symbol))
  :set (lambda (sym val)
         (set-default sym val)
         ;; Clean up `after-load-alist' first.
         (setq after-load-alist
               (delq nil
                     (mapcar (lambda (rec)
                               (unless (equal (cadr rec)
                                              '(majmodpri-start-idle-sort))
                                 rec))
                             after-load-alist)))
         (when val
           (if (not (listp val))
               (add-to-list 'after-load-alist
                            '(".*" (majmodpri-start-idle-sort)))
             (dolist (feat val)
               (unless (featurep feat)
                 (eval-after-load feat '(majmodpri-start-idle-sort)))))
           (majmodpri-start-idle-sort)))
  :group 'majmodpri)

(defcustom majmodpri-lists-to-sort
  '(magic-mode-alist auto-mode-alist magic-fallback-mode-alist)
  ;;nil
  "Which major mode lists to sort.
See `majmodpri-sort-lists' for more information."
  :type '(set (const magic-mode-alist)
              (const auto-mode-alist)
              (const magic-fallback-mode-alist))
  :set (lambda (sym val)
         (set-default sym val)
         (when majmodpri-sort-after-load
           (majmodpri-start-idle-sort)))
  :group 'majmodpri)

(defcustom majmodpri-mode-priorities
  '(
    cperl-mumamo-mode
    csound-sgml-mumamo-mode
    django-nxhtml-mumamo-mode
    django-html-mumamo-mode
    embperl-nxhtml-mumamo-mode
    embperl-html-mumamo-mode
    eruby-nxhtml-mumamo-mode
    eruby-html-mumamo-mode
    genshi-nxhtml-mumamo-mode
    genshi-html-mumamo-mode
    jsp-nxhtml-mumamo-mode
    jsp-html-mumamo-mode
    laszlo-nxml-mumamo-mode
    metapost-mumamo-mode
    mjt-nxhtml-mumamo-mode
    mjt-html-mumamo-mode
    noweb2-mumamo-mode
    ;;org-mumamo-mode
    perl-mumamo-mode
    smarty-nxhtml-mumamo-mode
    smarty-html-mumamo-mode
    ;;tt-html-mumamo-mode

    nxhtml-mumamo-mode
    html-mumamo-mode
    nxml-mumamo-mode
    nxml-mode

    rhtml-mode
    )
  "Priority list for major modes.
Modes that comes first have higher priority.
See `majmodpri-sort-lists' for more information."
  :type '(repeat symbol)
  :set (lambda (sym val)
         (set-default sym val)
         (when majmodpri-sort-after-load
           (majmodpri-start-idle-sort)))
  :group 'majmodpri)


;;;; Sorting

(defvar majmodpri-schwarzian-ordnum nil)
(defun majmodpri-schwarzian-in (rec)
  "Transform REC before sorting."
  (setq majmodpri-schwarzian-ordnum (1+ majmodpri-schwarzian-ordnum))
  (let ((mode (cdr rec)))
    (list
     (list mode majmodpri-schwarzian-ordnum)
     rec)))

(defun majmodpri-schwarzian-out (rec)
  "Get original value of REC after sorting."
  (cadr rec))

(defsubst majmodpri-priority (mode)
  "Return major mode MODE priority."
  (length (memq mode majmodpri-mode-priorities)))

(defun majmodpri-compare-auto-modes (rec1 rec2)
  "Compare record REC1 and record REC2.
Comparision:

- First check `majmodpri-mode-priorities'.
- Then use old order in list."
  (let* ((schw1 (car rec1))
         (schw2 (car rec2))
         (mod1     (nth 0 schw1))
         (mod2     (nth 0 schw2))
         (ord1     (nth 1 schw1))
         (ord2     (nth 1 schw2))
         (pri1 (majmodpri-priority mod1))
         (pri2 (majmodpri-priority mod2)))
    (cond
     ((/= pri1 pri2) (> pri1 pri2))
     (t (> ord1 ord2)))))

;;(benchmark 100 (quote (majmodpri-sort-lists)))
;;(defvar my-auto-mode-alist nil)
(defun majmodpri-sort-auto-mode-alist ()
  "Sort `auto-mode-alist' after users priorities."
  (setq majmodpri-schwarzian-ordnum 0)
  ;; Do not reorder function part, but put it first.
  (let (fun-list
        mod-list)
    (dolist (rec auto-mode-alist)
      (if (listp (cdr rec))
          (setq fun-list (cons rec fun-list))
        (setq mod-list (cons rec mod-list))))
    (setq fun-list (nreverse fun-list))
    (setq auto-mode-alist
          (append
           fun-list
           (mapcar 'majmodpri-schwarzian-out
                   (sort
                    (mapcar 'majmodpri-schwarzian-in mod-list)
                    'majmodpri-compare-auto-modes))))))

(defun majmodpri-sort-magic-list (magic-mode-list-sym)
  "Sort list MAGIC-MODE-LIST-SYM after users priorities."
  (let ((orig-ordnum 0))
    (set magic-mode-list-sym
         ;; S out
         (mapcar (lambda (rec)
                   (cadr rec))
                 ;; Sort
                 (sort
                  ;; S in
                  (mapcar (lambda (rec)
                            (setq orig-ordnum (1+ orig-ordnum))
                            (let ((mode (cdr rec)))
                              (list
                               (list mode orig-ordnum)
                               rec)))
                          (symbol-value magic-mode-list-sym))
                  (lambda (rec1 rec2)
                    (let* ((schw1 (car rec1))
                           (schw2 (car rec2))
                           (mod1 (nth 0 schw1))
                           (mod2 (nth 0 schw2))
                           (ord1 (nth 1 schw1))
                           (ord2 (nth 1 schw2))
                           (pri1 (majmodpri-priority mod1))
                           (pri2 (majmodpri-priority mod2)))
                      (cond
                       ((/= pri1 pri2) (> pri1 pri2))
                       (t (> ord1 ord2))))))))))

(defun majmodpri-sort-lists ()
  "Sort the list used when selecting major mode.
Only sort those lists choosen in `majmodpri-lists-to-sort'.
Sort according to priorities in `majmodpri-mode-priorities'.
Keep the old order in the list otherwise.

The lists can be sorted when loading elisp libraries, see
`majmodpri-sort-after-load'.

See also `majmodpri-apply-priorities'."
  (interactive)
  (message "majmodpri-sort-lists running ...")
  (majmodpri-cancel-idle-sort)
  (when (memq 'magic-mode-alist majmodpri-lists-to-sort)
    (majmodpri-sort-magic-list 'magic-mode-alist))
  (when (memq 'auto-mode-alist majmodpri-lists-to-sort)
    (majmodpri-sort-auto-mode-alist))
  (when (memq 'magic-fallback-mode-alist majmodpri-lists-to-sort)
    (majmodpri-sort-magic-list 'magic-fallback-mode-alist)))


(defun majmodpri-apply-priorities (change-modes)
  "Apply major mode priorities.
First run `majmodpri-sort-lists' and then if CHANGE-MODES is
non-nil apply to existing file buffers.  If interactive ask
before applying."
  (interactive '(nil))
  (majmodpri-sort-lists)
  (when (or change-modes
            (called-interactively-p))
    (let (file-buffers)
      (dolist (buffer (buffer-list))
        (with-current-buffer buffer
          (let ((name (buffer-name))
                (file buffer-file-name))
            (or (string= (substring name 0 1) " ") ;; Internal
                (not file)
                (setq file-buffers (cons buffer file-buffers))))))
      (if (not file-buffers)
          (when change-modes
            (message "No file buffers to change modes in"))
        (when (called-interactively-p)
          (setq change-modes
                (y-or-n-p "Check major mode in all file visiting buffers? ")))
        (when change-modes
          (dolist (buffer file-buffers)
            (with-current-buffer buffer (normal-mode))))))))


(provide 'majmodpri)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; majmodpri.el ends here

Re: Specifying mode in file variables trouble

[Richard M. Stallman]

    I am not sure. I liked html+php-mode better.

    Maybe using the name php-mode would also create confusion since the name
    is already in use.

I don't see the problem.  Would anyone now in the habit of running
`pho-mode' be disappointed after this change?

    I have suggested a different solution to this quite general problem. I
    think a list of major mode priorities would be better. I have
    implemented that in majmodpri.el which I am resending here.

I do not see how majmodpri would help solve this problem.
It does not seem relevant.

Here's the scenario: the user visits a file called foo.php which
contains code in various languages.  How do you propose for Emacs
to pick the right major mode?

I proposed two solutions:

* Always call `php-mode', and define `php-mode' using mumamo to handle
all the languages that can be in a PHP file.

* Always call `php-mode', and define `php-mode' to handle all the
languages that are found in this PHP file.

Re: Specifying mode in file variables trouble

[Lennart Borgman (gmail)]

Richard M. Stallman wrote:
>     I am not sure. I liked html+php-mode better.
> 
>     Maybe using the name php-mode would also create confusion since the name
>     is already in use.
> 
> I don't see the problem.  Would anyone now in the habit of running
> `php-mode' be disappointed after this change?

I don't know for sure, but some people seem to want to use just php-mode
instead of the solution with mumamo. It is not clear to me why and if
some people still prefer that.

It might be that they find mumamo complex or that they do not want the
whole of nXhtml.

It might also be because some php files actually contains only php code.

>     I have suggested a different solution to this quite general problem. I
>     think a list of major mode priorities would be better. I have
>     implemented that in majmodpri.el which I am resending here.
> 
> I do not see how majmodpri would help solve this problem.
> It does not seem relevant.

Again, as in my previous message (to your other message), I think the
commentary in majmodpri explains why majmodpri.el is relevant.

> Here's the scenario: the user visits a file called foo.php which
> contains code in various languages.  How do you propose for Emacs
> to pick the right major mode?

I propose that Emacs uses the same mechanism as today. That means that
the order of the entries in `auto-mode-alist' is used.

But I want to give the user control over the order in `auto-mode-alist'.
That is what majmodpri.el is for.

> I proposed two solutions:
> 
> * Always call `php-mode', and define `php-mode' using mumamo to handle
> all the languages that can be in a PHP file.
> 
> * Always call `php-mode', and define `php-mode' to handle all the
> languages that are found in this PHP file.

I think the only reasonable way to do it is to use mumamo. (Maybe CEDET
can change that in the future, but I rather think that CEDET and mumamo
should cooperate.)

Re: Specifying mode in file variables trouble

[Richard M. Stallman]

    > Here's the scenario: the user visits a file called foo.php which
    > contains code in various languages.  How do you propose for Emacs
    > to pick the right major mode?

    I propose that Emacs uses the same mechanism as today. That means that
    the order of the entries in `auto-mode-alist' is used.

Sorry, that is just a part of the answer.  If you propose to do this
using auto-mode-alist, what are the items you think should be in
auto-mode-alist?  And in what order?

    But I want to give the user control over the order in `auto-mode-alist'.

When we figure out precisely what we would DO with `auto-mode-alist',
we could begin to think about whether such control is useful.

    > * Always call `php-mode', and define `php-mode' using mumamo to handle
    > all the languages that can be in a PHP file.
    > 
    > * Always call `php-mode', and define `php-mode' to handle all the
    > languages that are found in this PHP file.

    I think the only reasonable way to do it is to use mumamo. (Maybe CEDET
    can change that in the future, but I rather think that CEDET and mumamo
    should cooperate.)

If that means using the first of my proposals,
that only requires one item in `auto-mode-alist',
so there is no issue about the order of them.

Re: Specifying mode in file variables trouble

[Richard M. Stallman]

    I don't know for sure, but some people seem to want to use just php-mode
    instead of the solution with mumamo. It is not clear to me why and if
    some people still prefer that.

Please ask them.  That answer is the most important of all!

Re: Specifying mode in file variables trouble

[Lennart Borgman (gmail)]

Richard M. Stallman wrote:
>     I don't know for sure, but some people seem to want to use just php-mode
>     instead of the solution with mumamo. It is not clear to me why and if
>     some people still prefer that.
> 
> Please ask them.  That answer is the most important of all!

I have done that, but a while ago. It seems like the arguments were
something like:

- They think using MuMaMo means that they have to learn more.
- MuMaMo is more complicated and that may mean more trouble
- Some believe that they might loose control.
- There is also more code to download since nXhtml is rather large.

I can't say these arguments are invalid. I have however tried to
simplify things as much as possible on the user level and I do not know
for sure what people think now.

Re: Specifying mode in file variables trouble

[Richard M. Stallman]

    - They think using MuMaMo means that they have to learn more.
    - MuMaMo is more complicated and that may mean more trouble
    - Some believe that they might loose control.
    - There is also more code to download since nXhtml is rather large.

These are just worries, imaginary problems.
I don't think we should be very concerned about them.

When people can really try this, then we can see if there
are real problems.

Re: Specifying mode in file variables trouble

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Sep 25, 2008 at 01:49:19AM -0400, Richard M. Stallman wrote:
>     - They think using MuMaMo means that they have to learn more.
>     - MuMaMo is more complicated and that may mean more trouble
>     - Some believe that they might loose control.
>     - There is also more code to download since nXhtml is rather large.
> 
> These are just worries, imaginary problems.
> I don't think we should be very concerned about them.

I don't program PHP -- so take this with a grain of salt.

But I would be wary of pulling in a full-fledged XML machinery just to
edit (pure) PHP source just because it is sometimes embedded in (X)HTML
templates. And I would be --uh-- rather uneasy being told this to be
"imaginary problems".

As an analogy, I'm regularly irked by reglar GNU/Linux distros
installing Avahi-this or Evolution-that just because I want a music
player or a task calendar. I try to avoid those packages which pull
in half-a-world of stuff I don't need.

Just (half) a data point.

Regards
- -- tomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFI2y+dBcgs9XrR2kYRAiDHAJ4zczkVQ0NW4AVv7HuOeD2D7DagwgCfYMhH
YnyzQ//XMKPSc16Ss0KNyBw=
=aIVG
-----END PGP SIGNATURE-----

Re: Specifying mode in file variables trouble

[Paul R]

Hello Thomas,

On Thu, 25 Sep 2008 08:28:45 +0200, tomas@tuxteam.de said:

tomas> But I would be wary of pulling in a full-fledged XML machinery
tomas> just to edit (pure) PHP source just because it is sometimes
tomas> embedded in (X)HTML templates. And I would be --uh-- rather
tomas> uneasy being told this to be "imaginary problems".

The line has to be drawn at a point. We probably all agree that emacs
memory consumption is sufficiently low with respect to current
hardware. So I beleive this should not drive out features that make
emacs DTRT when visiting a file.

tomas> As an analogy, I'm regularly irked by reglar GNU/Linux distros
tomas> installing Avahi-this or Evolution-that just because I want
tomas> a music player or a task calendar. I try to avoid those
tomas> packages which pull in half-a-world of stuff I don't need.

I think this a different kind of problem (persistent storage
consumption). And some distros offer you to choose dependency at build
time, through build flags. Distros you are talking about are probably
designed for ease of use and least surprise, and I bet they perform
very well in this field. Aren't they ?

BTW, I hope we can get emacs distribution more modular during next
cycle, so that you would not have to download and build a complex php
mode if you never edit php.

-- 
  Paul

Re: Specifying mode in file variables trouble

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Sep 25, 2008 at 08:41:22AM +0200, Paul R wrote:
> Hello Thomas,
> 
> On Thu, 25 Sep 2008 08:28:45 +0200, tomas@tuxteam.de said:
> 
> tomas> But I would be wary of pulling in a full-fledged XML machinery
> tomas> just to edit (pure) PHP source [...]

> The line has to be drawn at a point. We probably all agree that emacs
> memory consumption is sufficiently low with respect to current
> hardware. So I beleive this should not drive out features that make
> emacs DTRT when visiting a file.

It's only partially the computer's resources I am worried about. It's my
limited brain. I like the feeling I understand the tools I use (to some
extent).

> tomas> As an analogy, I'm regularly irked by reglar GNU/Linux distros
> tomas> installing Avahi-this or Evolution-that [...]

> I think this a different kind of problem (persistent storage
> consumption). And some distros offer you to choose dependency at build
> time, through build flags. Distros you are talking about are probably
> designed for ease of use and least surprise, and I bet they perform
> very well in this field. Aren't they ?

They do now, but you see a growing tendency of everything-depending-on-
everything-else, which is a pity, really. Because this modularity was a
strength of the UNIX-like systems.

> BTW, I hope we can get emacs distribution more modular during next
> cycle, so that you would not have to download and build a complex php
> mode if you never edit php.

This is a goal in itself, but the point I was trying to make is: if I
was a PHP programmer, I probably wouldn't like to have the whole
XML/HTML kaboodle in that as well *unless I needed it*. It was a plea to
make the mumamo approach itself more modular (I do applaud the multiple
major modes work very strongly!).

Regards
- -- tomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFI20QABcgs9XrR2kYRAnlwAJsG/qcwlfbCBC32qVX2bJYOf1z0mwCfUpWq
rI0jBNIOLva0XI1cbte/TJQ=
=j/S4
-----END PGP SIGNATURE-----

Re: Specifying mode in file variables trouble

[Paul R]

On Thu, 25 Sep 2008 09:55:44 +0200, tomas@tuxteam.de said:
tomas> [snip]                      I probably wouldn't like to have
tomas> the whole XML/HTML kaboodle in that as well *unless I needed
tomas> it*.

I guess it would not be triggered unless the point is inside an XML
region. IOW, you would not see the whole XML kaboodle unless you
actually need it. Lennart, can you confirm ?

-- 
  Paul

Re: Specifying mode in file variables trouble

[Lennart Borgman]

On Thu, Sep 25, 2008 at 10:35 AM, Paul R <paul.r.ml@gmail.com> wrote:
> On Thu, 25 Sep 2008 09:55:44 +0200, tomas@tuxteam.de said:
> tomas> [snip]                      I probably wouldn't like to have
> tomas> the whole XML/HTML kaboodle in that as well *unless I needed
> tomas> it*.
>
> I guess it would not be triggered unless the point is inside an XML
> region. IOW, you would not see the whole XML kaboodle unless you
> actually need it. Lennart, can you confirm ?


Thanks for asking, Paul. Actually I did a load a bit more than I think
is necessary for cases like files consisting of just PHP code and no
XHTML code. I just removed it. I don't think it is needed any more.

The heavy things should be autoloaded. Possibly I missed something. If
you find out please tell me.


When it comes to editing a PHP file there is actually three possibilities

1) Just using php-mode from php-mode.el.
2) html-mumamo-mode, which is 1 + mumamo + html-mode.
3) nxhtml-mumamo-mode, which is 1 + mumamo + nxhtml-mode

Number 2 here may perhaps be a good choice for those that does not
care about completion and validation in the XHTML parts. It is
possibly a bit smaller than 3 since html-mode is smaller than
nxhtml-mode (at least that is what I believe). And of course a little
bit less complicated since it does not offer the more accurate
completion in the XHTML parts that nxml-mode (nxhtml-mode) offers.

Personally I think 3 is the best, but then I of course knows about the
complexities.

(Note that the multi major mode names are not the ones used in the
released version of nXhtml.)

Re: Specifying mode in file variables trouble

[Richard M. Stallman]

    But I would be wary of pulling in a full-fledged XML machinery just to
    edit (pure) PHP source just because it is sometimes embedded in (X)HTML
    templates.

That would be a problem, but we can easily avoid it.  Here are two
ways.

* Make `php-mode' check whether there is HTML or XML in the file
and choose the mode accordingly.

* Arrange for mumamo not to call `nxml-mode' unless/until you move
point into an HTML chunk.

You're worried about a hypothetical problem in the detail of the
implementation.  That problem might happen, and if it does, we will
fix it.  So there is no point worrying about it now.

Re: Specifying mode in file variables trouble

[Lennart Borgman (gmail)]

Richard M. Stallman wrote:
>     But I would be wary of pulling in a full-fledged XML machinery just to
>     edit (pure) PHP source just because it is sometimes embedded in (X)HTML
>     templates.
> 
> That would be a problem, but we can easily avoid it.  Here are two
> ways.
> 
> * Make `php-mode' check whether there is HTML or XML in the file
> and choose the mode accordingly.
> 
> * Arrange for mumamo not to call `nxml-mode' unless/until you move
> point into an HTML chunk.

This is the way I have implemented it now, a major mode is not loaded by
mumamo until you move into a chunk where this major mode is used.

Re: Specifying mode in file variables trouble

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Oct 21, 2008 at 09:16:49PM +0200, Lennart Borgman (gmail) wrote:

[...]

> This is the way I have implemented it now, a major mode is not loaded by
> mumamo until you move into a chunk where this major mode is used.

Thanks, sounds great :-)

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFI/rhKBcgs9XrR2kYRAmNyAJ9bvKdvWFyJ1m3Xl0Azqzo1jmqUzwCfW7rA
VlE0zEi3TmNyUeYStxxM40w=
=1Isi
-----END PGP SIGNATURE-----

Re: Specifying mode in file variables trouble

[Richard M. Stallman]

    > * Arrange for mumamo not to call `nxml-mode' unless/until you move
    > point into an HTML chunk.

    This is the way I have implemented it now, a major mode is not loaded by
    mumamo until you move into a chunk where this major mode is used.

That is good.  So it is fine if php-mode always sets up to use mumamo.

Re: Specifying mode in file variables trouble

[Richard M. Stallman]

The "idle sorting" mechanism in majmodpri.el is asking for trouble.
Loading a file should _fully_ install the code in that file.  To leave
_anything_ for later is unreliable.

I'm not sure whether majmodpri is a useful feature, because I am not
convinced there is a real problem to be solved.  What is a real case
of the problem, and is there another solution?

But if we want such a facility, we should implement it right.  The
right way is to insert these elements in the proper position the first
time.

Re: Specifying mode in file variables trouble

[Lennart Borgman (gmail)]

Richard M. Stallman wrote:
> The "idle sorting" mechanism in majmodpri.el is asking for trouble.
> Loading a file should _fully_ install the code in that file.  To leave
> _anything_ for later is unreliable.

The "idle sorting" is there to avoid unnecessary sorting. It has a delay
of 0 so for most interactive use there will be no problems.

However I agree with your general point. If this is integrated in Emacs
I hope it will be quite easy to find some points where sorting most be
started if not done before. (This can perhaps be in addition to the
"idle sorting".)

> I'm not sure whether majmodpri is a useful feature, because I am not
> convinced there is a real problem to be solved.  What is a real case
> of the problem, and is there another solution?

I tried to describe the problem in the comment in majmodpri.el. Is that
comment not clear?

> But if we want such a facility, we should implement it right.  The
> right way is to insert these elements in the proper position the first
> time.

Unfortunately that can't be done. Please see the comment above.

Re: Specifying mode in file variables trouble

[Richard M. Stallman]

    > I'm not sure whether majmodpri is a useful feature, because I am not
    > convinced there is a real problem to be solved.  What is a real case
    > of the problem, and is there another solution?

    I tried to describe the problem in the comment in majmodpri.el. Is that
    comment not clear?

I can see what feature the file implements, for controlling the order
of `auto-mode-alist' and a few other variables.  I do not see that the
feature is useful.

If you show me a REAL case in which this is useful, that might convice me.

I am not impressed by imaginary hypothetical cases.

    > But if we want such a facility, we should implement it right.  The
    > right way is to insert these elements in the proper position the first
    > time.

    Unfortunately that can't be done. Please see the comment above.

Of course it can be done.  It is easy to write a function that would
add an item to `auto-mode-alist' and choose where to put it based on
whatever criteria we like.  It could take four three arguments, one
being the major mode that the elements are for, and the other three
being elements to add to the three variables that majmodpri sorts.
And it could insert them in the proper order.

I don't know if it is useful, but it is not hard.

Re: Specifying mode in file variables trouble

[Lennart Borgman (gmail)]

Richard M. Stallman wrote:
>     > I'm not sure whether majmodpri is a useful feature, because I am not
>     > convinced there is a real problem to be solved.  What is a real case
>     > of the problem, and is there another solution?
> 
>     I tried to describe the problem in the comment in majmodpri.el. Is that
>     comment not clear?
> 
> I can see what feature the file implements, for controlling the order
> of `auto-mode-alist' and a few other variables.  I do not see that the
> feature is useful.
> 
> If you show me a REAL case in which this is useful, that might convice me.

When I wrote the majmodpri.el I had third party elisp files in mind. For
files inside Emacs we can perhaps use a simpler mechanism.

It is quite common that third party files adds themselves to
auto-mode-alist when they are loaded. At least some of the php-mode.el
varianst that are available does that; they bind .php to the php-mode
the supply. This will then be the default major mode for .php files.

We can of course say that should not have this side effect, but that
does not help all times. (We have already done that.)

This problem actually exists inside Emacs too. Today there are two major
modes for editing XML files.

majmodpri.el offers a way to solve this type of problem through custom
(though it may of course need some changes).


> I am not impressed by imaginary hypothetical cases.
> 
>     > But if we want such a facility, we should implement it right.  The
>     > right way is to insert these elements in the proper position the first
>     > time.
> 
>     Unfortunately that can't be done. Please see the comment above.
> 
> Of course it can be done.

Yes, but this is a misunderstanding. I was thinking of the problems I
wrote about above.

> It is easy to write a function that would
> add an item to `auto-mode-alist' and choose where to put it based on
> whatever criteria we like.  It could take four three arguments, one
> being the major mode that the elements are for, and the other three
> being elements to add to the three variables that majmodpri sorts.
> And it could insert them in the proper order.
> 
> I don't know if it is useful, but it is not hard.

Re: Specifying mode in file variables trouble

[Richard M. Stallman]

    > If you show me a REAL case in which this is useful, that might convice me.

    When I wrote the majmodpri.el I had third party elisp files in mind.

If show us a real case involving third party Elisp files, we can
look at whether there is a problem, and if so what solutions may be
possible.

My hunch is that this is not the best solution for any case,
but until I see the cases, I cannot be sure.

    At least some of the php-mode.el
    varianst that are available does that; they bind .php to the php-mode
    the supply. This will then be the default major mode for .php files.

When we have a builtin php-mode (perhaps one that uses mumamo), we
will of course tell people they should modify those packages or stop
using them.

    This problem actually exists inside Emacs too. Today there are two major
    modes for editing XML files.

Why are both present?

Please say more about that situation, so I can think about what best
to do.

Re: Specifying mode in file variables trouble

[Lennart Borgman (gmail)]

Richard M. Stallman wrote:
> The "idle sorting" mechanism in majmodpri.el is asking for trouble.
> Loading a file should _fully_ install the code in that file.  To leave
> _anything_ for later is unreliable.
> 
> I'm not sure whether majmodpri is a useful feature, because I am not
> convinced there is a real problem to be solved.  What is a real case
> of the problem, and is there another solution?
> 
> But if we want such a facility, we should implement it right.  The
> right way is to insert these elements in the proper position the first
> time.

I think I am beeing a bit stupid here. I should have said before that
the implementation in majmodpri.el is for the case that this feature is
not included in Emacs. If it is included in Emacs it can be done much
more simple.

What majmodpri.el does is effectively that it implements a priority list
beside the lists used by `normal-mode'. (And it makes this list
customizable.)

If we include this in Emacs I would suggest something similar to what I
have used in mumamo in `mumamo-major-modes'. This is for a different
purpose but the structure of the problem is sufficiently similar.

That list is used for converting what I call major mode specifiers to
major modes. Major modes are used when definiing multi major modes.

An example is the major mode specifier for javascript. I call this
javascript-mode. In mumamo-major-modes this is used as a key to find the
major mode to use:

(defcustom mumamo-major-modes
  '(
    (javascript-mode
     javascript-mode
     js2-fl-mode
     ecmascript-mode)
    (java-mode
     jde-mode
     java-mode)
    )

If a multi major mode has a major mode specifier for a chunk that is
javascript-mode this will result in a lookup in this list and give the
result (javascript-mode js2-fl-mode ecmasript-mode). These three are
major modes ordered in priority order. If javascript-mode is available
that will be used, else js2-fl-mode etc.

A similar implementation can be used for major mode priorities for
normal-mode. Then there is no need at all to change the lists
normal-mode uses (but I have to do that in majmodpri.el because I can't
change the way normal-mode behaves).

Re: Specifying mode in file variables trouble

[Richard M. Stallman]

    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.

Imenu is much more complex than a typical minor mode.  I think it
would be useful to first look at simple cases such as Auto Fill mode.
Does Auto Fill mode work ok with mumamo now?

We should first look for a solution that enables Mumamo to DTRT
automatically with most minor modes.

If that is not possible, than let's look for way to make minor
mode definitions specify the info that mumamo needs.

Let's design this for maximum simplicity and cleanness of the minor
mode definitions, rather than for maximum power and flexibility.
I'd rather see a feature that does only what most minor modes need
and is very simple.

If Imenu needs something more complex, we could also have a second
feature which is more complex and less clean, and Imenu could use
that.

Re: Specifying mode in file variables trouble

[Lennart Borgman (gmail)]

Richard M. Stallman wrote:
>     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.
> 
> Imenu is much more complex than a typical minor mode.  I think it
> would be useful to first look at simple cases such as Auto Fill mode.
> Does Auto Fill mode work ok with mumamo now?
> 
> We should first look for a solution that enables Mumamo to DTRT
> automatically with most minor modes.
> 
> If that is not possible, than let's look for way to make minor
> mode definitions specify the info that mumamo needs.
> 
> Let's design this for maximum simplicity and cleanness of the minor
> mode definitions, rather than for maximum power and flexibility.
> I'd rather see a feature that does only what most minor modes need
> and is very simple.

How about the solutin I sent with mumamo-save-buffer-locals and dito
restore? I suggested something like this

  (mumamo-save-buffer-locals major-mode)
  (funcall new-major-mode)
  (mumamo-restore-buffer-locals new-major-mode)

There is however a problem with this and the major mode hook. Things in
this hook might want to change some buffer local variables.

I think putting the restore part first in the mode solves some part of
the problem. For this to work however delay-mode-hooks must be temporary
 set to nil (see the sources for `run-mode-hooks'). I have no idea what
delayed-mode-hooks is used for so I do not know if setting
delay-mode-hooks to nil may cause problems here.

> If Imenu needs something more complex, we could also have a second
> feature which is more complex and less clean, and Imenu could use
> that.

Re: Specifying mode in file variables trouble

[Stefan Monnier]

>  set to nil (see the sources for `run-mode-hooks'). I have no idea what
> delayed-mode-hooks is used for so I do not know if setting

It is used so that the parent mode hook is run at the end of the (child)
major mode, so that the user's hook functions (placed on the parent
hook) can take into account the variable values set by the child.


        Stefan

Re: Specifying mode in file variables trouble

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
>>  set to nil (see the sources for `run-mode-hooks'). I have no idea what
>> delayed-mode-hooks is used for so I do not know if setting
> 
> It is used so that the parent mode hook is run at the end of the (child)
> major mode, so that the user's hook functions (placed on the parent
> hook) can take into account the variable values set by the child.


Thanks. I might be beginning to understand. From what you wrote above
and the somewhat scarse documentation I draw the conclusion that in
normal case the child major modes mode hook is run before the parent
major modes mode hook.

So the order of running the hooks is

   childs local mode hook
     which also include running childs global hook (at the `t')
   parents' mode hooks

If this is correct then I think that adding the call to
mumamo-restore-most-buffer-locals first in the childs local mode hook
would be the best.

The values thus restored can then be changed by things coming later in
the mode hooks.

Since it looks like delay-mode-hook is something that we should not
touch in case we are not the macro delay-mode-hook this is nothing we
have to care about.

So this is what I have got now:

    ;; Save local variables before switching major
    (mumamo-save-most-buffer-locals major-mode)
    ;; Restore local variables after switching, but do it in the mode
    ;; hook:
    (let ((mode-hook (intern-soft (concat (symbol-name major) "-hook")))
          (restore-fun (lambda ()
                         (mumamo-restore-most-buffer-locals major))))
      (when mode-hook
        ;; Put first in local hook to run it first:
        (add-hook mode-hook restore-fun nil t))
      (funcall major) ;; <------- This is the major mode change
      (if (not mode-hook)
          (mumamo-restore-most-buffer-locals major)
        (remove-hook mode-hook restore-fun t)))

Re: Specifying mode in file variables trouble

[Stefan Monnier]

> So the order of running the hooks is

>    childs local mode hook
>      which also include running childs global hook (at the `t')
>    parents' mode hooks

No.  Without the delay-mode-hooks thingy, the way it works is:

   <parent-mode code>;
   <parent-mode hook, which also includes global ones>;
   <child-mode code>;
   <child-mode hook, which also includes global ones>;

while the delay-mode-hooks trick changes it to:

   <parent-mode code>;
   <child-mode code>;
   <parent-mode hook, which also includes global ones>;
   <child-mode hook, which also includes global ones>;

> If this is correct then I think that adding the call to
> mumamo-restore-most-buffer-locals first in the childs local mode hook
> would be the best.

It sounds like you want it first in the parent's mode hook.


        Stefan

Re: Specifying mode in file variables trouble

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
>> So the order of running the hooks is
> 
>>    childs local mode hook
>>      which also include running childs global hook (at the `t')
>>    parents' mode hooks
> 
> No.  Without the delay-mode-hooks thingy, the way it works is:
> 
>    <parent-mode code>;
>    <parent-mode hook, which also includes global ones>;
>    <child-mode code>;
>    <child-mode hook, which also includes global ones>;
> 
> while the delay-mode-hooks trick changes it to:
> 
>    <parent-mode code>;
>    <child-mode code>;
>    <parent-mode hook, which also includes global ones>;
>    <child-mode hook, which also includes global ones>;

Ehm. Yes, thanks.

>> If this is correct then I think that adding the call to
>> mumamo-restore-most-buffer-locals first in the childs local mode hook
>> would be the best.
> 
> It sounds like you want it first in the parent's mode hook.


Yes, I think I fall for wishfull thinking there.

That is some more lines to implement ;-)

Re: Specifying mode in file variables trouble

[Stefan Monnier]

>> It sounds like you want it first in the parent's mode hook.
> Yes, I think I fall for wishfull thinking there.
> That is some more lines to implement ;-)

If you can arrange for all the relevant modes to derive from some new
`universal-parent-mode', then you just need to make it be first on
`universal-parent-mode-hook'.


        Stefan

Re: Specifying mode in file variables trouble

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
>>> It sounds like you want it first in the parent's mode hook.
>> Yes, I think I fall for wishfull thinking there.
>> That is some more lines to implement ;-)
> 
> If you can arrange for all the relevant modes to derive from some new
> `universal-parent-mode', then you just need to make it be first on
> `universal-parent-mode-hook'.


But I do not write most of the major modes. They come from all over the
world ...

I just implemented the code:

    ;; Save local variables before switching major
    (mumamo-save-most-buffer-locals major-mode)
    ;; Restore local variables after switching, but do it in the
    ;; greatest ancestor's mode hook (see `run-mode-hooks'):
    (let (ancestor-hook-sym
          parent-hook-sym
          (parent major-mode)
          (restore-fun (lambda ()
                         (mumamo-restore-most-buffer-locals major))))
      ;; We want the greatest ancestor's mode hook:
      (setq parent-hook-sym (intern-soft (concat (symbol-name parent)
"-hook")))
      (when parent-hook-sym (setq ancestor-hook-sym parent-hook-sym))
      (while (get parent 'derived-mode-parent)
        (setq parent (get parent 'derived-mode-parent))
        (setq parent-hook-sym (intern-soft (concat (symbol-name parent)
"-hook")))
        (when parent-hook-sym (setq ancestor-hook-sym parent-hook-sym)))
      (when ancestor-hook-sym
        ;; Put first in local hook to run it first:
        (add-hook ancestor-hook-sym restore-fun nil t))
      (funcall major) ;; <-------------- Change major mode here
      (if (not ancestor-hook-sym)
          (mumamo-restore-most-buffer-locals major)
        (remove-hook ancestor-hook-sym restore-fun t)))

Re: Specifying mode in file variables trouble

[Richard M. Stallman]

    But I do not write most of the major modes. They come from all over the
    world ...

If we want all major modes to do something different, we can change
the functions `kill-all-local-variables' and `run-hooks'.

Re: Specifying mode in file variables trouble

[Lennart Borgman (gmail)]

Richard M. Stallman wrote:
>     But I do not write most of the major modes. They come from all over the
>     world ...
> 
> If we want all major modes to do something different, we can change
> the functions `kill-all-local-variables' and `run-hooks'.

Yes, that could be a way, but I think we first have to think about how,
when and which buffer local variables should survive moving between
chunks with different major modes. I have thought about three different
cases:

- Buffer local variables that should never survive moving between chunks
with different major modes.

- Those that always should survive (but be killed when switching major
modes when mumamo is not used).

- Those that will be killed when moving to a chunk with a different
major mode, but will be resurrected when point again reaches a chunk
with the same major mode. (They are what I call "per major mode".)

Re: Specifying mode in file variables trouble

[Richard M. Stallman]

    > If we want all major modes to do something different, we can change
    > the functions `kill-all-local-variables' and `run-hooks'.

    Yes, that could be a way, but I think we first have to think about how,
    when and which buffer local variables should survive moving between
    chunks with different major modes.

Yes, exactly.  Before proposing mechanisms, the first step is to look
at what the cases are and see what behavior we want.

				       I have thought about three different
    cases:

    - Buffer local variables that should never survive moving between chunks
    with different major modes.

    - Those that always should survive (but be killed when switching major
    modes when mumamo is not used).

    - Those that will be killed when moving to a chunk with a different
    major mode, but will be resurrected when point again reaches a chunk
    with the same major mode. (They are what I call "per major mode".)

I agree that these three behaviors should suffice.  (We also want
variables that survive all changes in major mode, and that's what
`permanent-local' does now.)

Do we need all these behaviors?

I doubt that the first behavior is needed, except for a few variables
used specially in the implementation of mumamo.  Mumamo can easily
implement that behavior for those few variables.

Can you find any other use cases for which the first behavior is needed?
If not, let's forget it.

I think the second and third behaviors are both useful.  So the next step
is to design conditions under which each one should happen.

To do that, we need to see the _pattern_ of when each behavior is
desired.  So please collect use cases for them.

Here's a proposal that came to me, suggested by what I know about
use-case patterns.

    * If a variable is bound locally by one of the major modes used within
    mumamo, or by the mode hooks it runs, then kill it when moving to a
    chunk in another major mode.

    * Any other buffer-local variable should survive through motion between
    chunks.

Can you find any use cases where this would not be right?

Re: Specifying mode in file variables trouble

[Lennart Borgman (gmail)]

Richard M. Stallman wrote:
>     I have thought about three different
>     cases:
> 
>     - Buffer local variables that should never survive moving between chunks
>     with different major modes.
> 
>     - Those that always should survive (but be killed when switching major
>     modes when mumamo is not used).
> 
>     - Those that will be killed when moving to a chunk with a different
>     major mode, but will be resurrected when point again reaches a chunk
>     with the same major mode. (They are what I call "per major mode".)
> 
> I agree that these three behaviors should suffice.  (We also want
> variables that survive all changes in major mode, and that's what
> `permanent-local' does now.)
> 
> Do we need all these behaviors?
> 
> I doubt that the first behavior is needed, except for a few variables
> used specially in the implementation of mumamo.  Mumamo can easily
> implement that behavior for those few variables.

Maybe it would be meaningful for a parser that is supporting completion
in the chunk?

> Can you find any other use cases for which the first behavior is needed?
> If not, let's forget it.
> 
> I think the second and third behaviors are both useful.  So the next step
> is to design conditions under which each one should happen.
> 
> To do that, we need to see the _pattern_ of when each behavior is
> desired.  So please collect use cases for them.
> 
> Here's a proposal that came to me, suggested by what I know about
> use-case patterns.
> 
>     * If a variable is bound locally by one of the major modes used within
>     mumamo, or by the mode hooks it runs, then kill it when moving to a
>     chunk in another major mode.

Do you mean the third case aboove here? I think this is a good idea.
This is what I have implemented now in the latest sources (and that I
sent here).

>     * Any other buffer-local variable should survive through motion between
>     chunks.

I am not sure about this one, but I think it would be better to use the
third case for these variables too (and that is what I do now) if not
their 'permanent-buffer local property is non-nil.

> Can you find any use cases where this would not be right?

Let say that the user for example want to use another indentation step
for a specific chunk type. Then my comment above would perhaps apply.

But you may of course say instead that such cases should be handled by
adding this to the major mode hook.

---
I am a bit worried by this complexity for the users. One way to avoid it
would perhaps to introduce the concept of a new "persistent level"
between 'permanent-local=t and 'permanent-local=nil. A level that would
be like 'permanent-local=t but just for the current buffer. Maybe
permanent-local could take the current buffer as a value for this level?

Re: Specifying mode in file variables trouble

[Richard M. Stallman]

    >     - Buffer local variables that should never survive moving between chunks
    >     with different major modes.

    > I doubt that the first behavior is needed, except for a few variables
    > used specially in the implementation of mumamo.  Mumamo can easily
    > implement that behavior for those few variables.

    Maybe it would be meaningful for a parser that is supporting completion
    in the chunk?

I don't understand what that means.  Would you please be more
specific?

Anyway, it sounds like something very specialized and very closely
related to mumamo.  It would be easy enough to add a special feature
to do this, if and when it is really wanted.

Which means that, for now, we can forget about this.

Re: Specifying mode in file variables trouble

[Richard M. Stallman]

    >     * If a variable is bound locally by one of the major modes used within
    >     mumamo, or by the mode hooks it runs, then kill it when moving to a
    >     chunk in another major mode.

    Do you mean the third case aboove here?

Yes.

					    I think this is a good idea.
    This is what I have implemented now in the latest sources (and that I
    sent here).

Ok.

    >     * Any other buffer-local variable should survive through motion between
    >     chunks.

    I am not sure about this one, but I think it would be better to use the
    third case for these variables too (and that is what I do now) if not
    their 'permanent-buffer local property is non-nil.

That is surely not right, because it means that almost all minor modes
can get lost when moving between chunks.

I think you should switch to what I proposed.

    > Can you find any use cases where this would not be right?

    Let say that the user for example want to use another indentation step
    for a specific chunk type. Then my comment above would perhaps apply.

How would a user specify variable values for particular chunk types?
Does mumamo have a facility for that?  I think only a special mumamo
facility could make this convenient.

That facility would implement whatever chunk-switching behavior is
most suitable.

So it looks my simple proposal is adequate.

    I am a bit worried by this complexity for the users.  One way to avoid it
    would perhaps to introduce the concept of a new "persistent level"
    between 'permanent-local=t and 'permanent-local=nil. A level that would
    be like 'permanent-local=t but just for the current buffer.

That might be a good idea if we really need it.
But my proposal is simpler:

     * If a variable is bound locally by one of the major modes used within
     mumamo, or by the mode hooks it runs, then kill it when moving to a
     chunk in another major mode.

     * Any other buffer-local variable should survive through motion between
     chunks.

So unless we see a use case for which this isn't right,
why not stick with it?

Selecting mumamo modes

[Richard M. Stallman]

Here's an idea.  Suppose that `normal-mode' sees that a file specifies
a major mode of the form `A+B'.  If there is no function `A+B-mode',
it could create one using mumamo, based on `A-mode' and `B-mode', and
then call it.

That is safe because it only lets a file call `A-mode' and `B-mode',
which files can already do individually.

Naturally the feature should handle cases of more than two modes in a
similar way.

Re: Selecting mumamo modes

[Lennart Borgman (gmail)]

Richard M. Stallman wrote:
> Here's an idea.  Suppose that `normal-mode' sees that a file specifies
> a major mode of the form `A+B'.  If there is no function `A+B-mode',
> it could create one using mumamo, based on `A-mode' and `B-mode', and
> then call it.

Let me see if I understand how you think here ;-)

The structural unit needed are those for defining the chunks. They must
contain info like:

a) B can contain A
b) a chunk dividing function for B in A
c) the major mode specifier A
d) the major mode specifier B
and maybe also
e) order relative to other such structural units; for chunk dividing.

If units like that are available then maybe something like you propose
can be done, yes.

But this is actually rather similar to what is done today in the
defmacro define-mumamo-multi-major-mode, isn't it? I can still see that
it may be useful, of course, but I do not find it necessary now.

Internally I think the structure above will be needed to allow
sub-chunks in sub-chunks. I am still in doubt about how to implement
that however.

* Some notes about sub-chunks in sub-chunks:

I think the best way to do sub-chunks in sub-chunks will be to always do
the chunk dividing from beginning of the file to the end of the file.
(And we could also require that the information about the sub-chunk
major mode should be in the beginning border.)

I have been hesitating to implement this because it might take to long
time if the user for example starts by jumping to the end of the file. A
way to solve that problem is perhaps to first guess the chunk from the
information at the buffer contents close to point and then just change
the chunk if needed when the chunk dividing running from beginning of
the file to the end has come to the chunk containing point.



> That is safe because it only lets a file call `A-mode' and `B-mode',
> which files can already do individually.
>
> Naturally the feature should handle cases of more than two modes in a
> similar way. 

Re: Selecting mumamo modes

[Richard M. Stallman]

    > Here's an idea.  Suppose that `normal-mode' sees that a file specifies
    > a major mode of the form `A+B'.  If there is no function `A+B-mode',
    > it could create one using mumamo, based on `A-mode' and `B-mode', and
    > then call it.

    Let me see if I understand how you think here ;-)

    The structural unit needed are those for defining the chunks. They must
    contain info like:

Are you saying that a list of major modes is not sufficient
for defining the mumamo mode to combine them.

If so, I guess my idea won't work.  Oh well.

Re: Selecting mumamo modes

[Lennart Borgman (gmail)]

Richard M. Stallman wrote:
>     > Here's an idea.  Suppose that `normal-mode' sees that a file specifies
>     > a major mode of the form `A+B'.  If there is no function `A+B-mode',
>     > it could create one using mumamo, based on `A-mode' and `B-mode', and
>     > then call it.
> 
>     Let me see if I understand how you think here ;-)
> 
>     The structural unit needed are those for defining the chunks. They must
>     contain info like:
> 
> Are you saying that a list of major modes is not sufficient
> for defining the mumamo mode to combine them.

Yes.

> If so, I guess my idea won't work.  Oh well.
> 

Re: Specifying mode in file variables trouble

[Richard M. Stallman]

    How about the solutin I sent with mumamo-save-buffer-locals and dito
    restore? I suggested something like this

That is a proposed _mechanism_.

Another mechanism which might be to put properties on the variables
that control minor modes.  Or perhaps just on per-buffer minor modes
(the ones that are not normally global).

By scanning buffer-local-variables and checking for that property,
you could find all the minor modes that are set in a given buffer.

The mechanism is just part of this.  We also need an interface.  There
are lots of minor mode definitions, and we want them to be simple and
clean.

So please propose a change in minor mode definitions so as to do the
job.  Then we can evaluate it and maybe propose better alternatives.

    I have no idea what
    delayed-mode-hooks is used for so I do not know if setting
    delay-mode-hooks to nil may cause problems here.

Please read the doc of the macro `delay-mode-hooks' to learn what this
does.

Re: Specifying mode in file variables trouble

[Lennart Borgman (gmail)]

Richard M. Stallman wrote:
>     How about the solutin I sent with mumamo-save-buffer-locals and dito
>     restore? I suggested something like this
> 
> That is a proposed _mechanism_.

Mm. Yes. It is clearly not the whole solution.

> Another mechanism which might be to put properties on the variables
> that control minor modes.  Or perhaps just on per-buffer minor modes
> (the ones that are not normally global).

There are three main scopes (maybe there are more) for minor modes:

- Global
- Per buffer
- Per major mode

Global minor modes are not a problem here.

I have suggested long ago using the existing mechanism for
distinguishing between local variables that are per buffer and those
that are per major mode. In other words: the minor modes that are per
buffer should use

   (put 'PER-BUFFER-VARIABLE 'permanent-local t)

on their buffer local variables. (I do that now in mumamo.el for some of
the most important.)

> By scanning buffer-local-variables and checking for that property,
> you could find all the minor modes that are set in a given buffer.

I believe I can see what you mean. It might however be better to do it
the other way round: mark those buffer local variables that are not used
by the type of minor modes we are talking about here.

The advantage is of course that minor mode authors most often will not
have to know about this.

I have implemented such a list in mumamo.el now. This is the variable
mumamo-buffer-locals-dont-set.

> The mechanism is just part of this.  We also need an interface.  There
> are lots of minor mode definitions, and we want them to be simple and
> clean.
> 
> So please propose a change in minor mode definitions so as to do the
> job.  Then we can evaluate it and maybe propose better alternatives.

I think the suggestions above may be sufficient, but that might be just
because of lack of imagination/knowledge of Emacs ;-)

>     I have no idea what
>     delayed-mode-hooks is used for so I do not know if setting
>     delay-mode-hooks to nil may cause problems here.
> 
> Please read the doc of the macro `delay-mode-hooks' to learn what this
> does.

Thanks. I did that after Stefan's reply. I think the doc strings for
delay-mode-hooks and the variable delayed-mode-hooks need a bit
enhancements, at least pointers to the macro.

Re: Specifying mode in file variables trouble

[Richard M. Stallman]

    There are three main scopes (maybe there are more) for minor modes:

    - Global
    - Per buffer

I think I know what those two mean.

    - Per major mode

What does that mean?  I don't know of that.

    Global minor modes are not a problem here.

Usually they are not; but if a minor mode is itself global,
you can make a buffer-local binding for the variable.

Perhaps when you speak of "global" and "per buffer"
you mean how the variable is bound, rather than how the mode
normally works.

    I have suggested long ago using the existing mechanism for
    distinguishing between local variables that are per buffer and those
    that are per major mode.

I don't understand that distinction, but I know that just about any
variable in Emacs _can_ be given a buffer-local binding by a major
mode command.  So is the distinction meaningful?

			     In other words: the minor modes that are per
    buffer should use

       (put 'PER-BUFFER-VARIABLE 'permanent-local t)

    on their buffer local variables. (I do that now in mumamo.el for some of
    the most important.)

I am not sure that change is correct.  When the variable is not marked
as permanent-local, that could mean we want major mode commands to
reset this minor mode.  Of course, moving between chunks in mumamo
should not reset it.

Can you tell us some of the variables for which you added that property?

Perhaps we want to have a different value for the `permanent-local' property
that applies only to mumamo.

Re: Specifying mode in file variables trouble

[Lennart Borgman (gmail)]

Richard M. Stallman wrote:
>     There are three main scopes (maybe there are more) for minor modes:
> 
>     - Global
>     - Per buffer
> 
> I think I know what those two mean.
> 
>     - Per major mode
> 
> What does that mean?  I don't know of that.

I mean minor modes that are used with specific major modes. Or any minor
mode that is turned on in a major mode hook.

>     Global minor modes are not a problem here.
> 
> Usually they are not; but if a minor mode is itself global,
> you can make a buffer-local binding for the variable.
> 
> Perhaps when you speak of "global" and "per buffer"
> you mean how the variable is bound, rather than how the mode
> normally works.

In this case, yes.

>     I have suggested long ago using the existing mechanism for
>     distinguishing between local variables that are per buffer and those
>     that are per major mode.
> 
> I don't understand that distinction, but I know that just about any
> variable in Emacs _can_ be given a buffer-local binding by a major
> mode command.  So is the distinction meaningful?

I think so. For example flymake works on the file regardless of the
major mode. If mumamo is used in the buffer then flymake should still
work on the file - which is in a sense the same as the whole buffer here.

> 			     In other words: the minor modes that are per
>     buffer should use
> 
>        (put 'PER-BUFFER-VARIABLE 'permanent-local t)
> 
>     on their buffer local variables. (I do that now in mumamo.el for some of
>     the most important.)
> 
> I am not sure that change is correct.  When the variable is not marked
> as permanent-local, that could mean we want major mode commands to
> reset this minor mode.  Of course, moving between chunks in mumamo
> should not reset it.

For cases like flymake we know that the minor mode is per buffer/file. I
think that will be true for many parsers (but we will have to help them
over "bad" chunks, ie chunks they do not expect to see).

The same is also true for emulators like viper.

For the cases above I think using (put 'PER-BUF-VAR 'permanent-local t)
is the right thing. In other cases we can't do even if we want the minor
modes (buffer local variables) to survive when point is moved to a new
chunk.

For that case I have implemented mumamo-survive, a list of variable
symbols that should survive when moving between chunks. Of course that
is a rather rough approximation. To refine it a bit I have now also
added save/restore of buffer local variables per major modes (see
earlier messages in this thread).

> Can you tell us some of the variables for which you added that property?
> 
> Perhaps we want to have a different value for the `permanent-local' property
> that applies only to mumamo.

Yes, perhaps. I think however we should first consider the structures
above and see if they are enough. (Then we can maybe implement them
using specific properties instead.)

Re: Specifying mode in file variables trouble

[Richard M. Stallman]

    I mean minor modes that are used with specific major modes.

Can you cite some examples so I can see what that means?

Re: Specifying mode in file variables trouble

[Lennart Borgman (gmail)]

Richard M. Stallman wrote:
>     I mean minor modes that are used with specific major modes.
> 
> Can you cite some examples so I can see what that means?

Ehm. I am not sure. I think people sometimes write such minor modes as
enhancements to major mode.

Re: Specifying mode in file variables trouble

[Richard M. Stallman]

    Ehm. I am not sure. I think people sometimes write such minor modes as
    enhancements to major mode.

I think there are such minormodes for C mode.  Please take a look at them
and see what behavior is right for them.

Re: Specifying mode in file variables trouble

[Richard M. Stallman]

    > The mechanism is just part of this.  We also need an interface.  There
    > are lots of minor mode definitions, and we want them to be simple and
    > clean.
    > 
    > So please propose a change in minor mode definitions so as to do the
    > job.  Then we can evaluate it and maybe propose better alternatives.

    I think the suggestions above may be sufficient, but that might be just
    because of lack of imagination/knowledge of Emacs ;-)

Please show how you would change a few of the existing minor mode definitions
to specify what to do here.

Re: Specifying mode in file variables trouble

[Lennart Borgman (gmail)]

Richard M. Stallman wrote:
>     > The mechanism is just part of this.  We also need an interface.  There
>     > are lots of minor mode definitions, and we want them to be simple and
>     > clean.
>     > 
>     > So please propose a change in minor mode definitions so as to do the
>     > job.  Then we can evaluate it and maybe propose better alternatives.
> 
>     I think the suggestions above may be sufficient, but that might be just
>     because of lack of imagination/knowledge of Emacs ;-)
> 
> Please show how you would change a few of the existing minor mode definitions
> to specify what to do here.

Good question. I am however not sure about it. What I am trying to do is
discuss the structures needed - though I sometimes gives them as
implementation examples.

The only thing I am quite sure about is that for what I call "per buffer
variables" we can use (put 'PER-BUF-VAR 'permanent-local t).

But when it comes to "per major modes" I am a bit confused. I just
realize that I made a mistake in my last post. I have (implicitly)
spoken about two different types of "per major modes" variables; those
that are reset every time a major mode function is called and those that
should be resurrected when point comes to a major mode with the same
major mode.

I have tried to make this distinction because the user may want to set
some buffer local variable for a major mode even in mumamo. I am not
sure this is a good distinction however.

I can see two ways to resolve it: either say that all such variables
should be set in major mode hooks. Or just resurrect all buffer local
variables (with some necessary exceptions) when arriving to a chunk with
the same major mode. If switching to a new major mode just where setting
some local variables this could be used instead of calling the major
mode function when moving between chunks (after the major mode has been
called once in the buffer and the buffer local values have been saved),
but it is not clear to me whether this would work. What do you think?

Re: Specifying mode in file variables trouble

[Stefan Monnier]

> In other words: Emacs adds "-mode". That is frustrating, but can of
> course not be changed. However if Emacs finds that this fails, can it
> then check for just the given "symbol"?

That'd be a security hole, since opening some random file might then
call any arbitrary function.


        Stefan

Re: Specifying mode in file variables trouble

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
>> In other words: Emacs adds "-mode". That is frustrating, but can of
>> course not be changed. However if Emacs finds that this fails, can it
>> then check for just the given "symbol"?
> 
> That'd be a security hole, since opening some random file might then
> call any arbitrary function.


Hm. Good point. I guess there is nothing to do about it then.