mode in -*- line

mode in -*- line

[Luc Teirlinck]

There are two things I noticed about modes in the -*- line.

Firstly, if normal-mode is called interactively, it unconditionally
processes all local variables in the -*- line and the local variables
list _except_ that it ignores a mode in the -*- line if
enable-local-variables is nil.  I guess that this exception is
unintentional.  If so, it is easy to fix.

Secondly, if I set enable-local-variables to 'ask and visit a file
with a mode in the -*- line, and then answer twice no to the questions
asking me whether I want to process local variables, then indeed no
local variables are processed, _except_ for the mode in the -*- line.
Is this intentional?  If not, this is a little bit trickier, because
the most obvious way to solve it would be to ask the user a third
question (in set-auto-mode) and two is already many.

Sincerely,

Luc.

Re: mode in -*- line

[Richard Stallman]

    Firstly, if normal-mode is called interactively, it unconditionally
    processes all local variables in the -*- line and the local variables
    list _except_ that it ignores a mode in the -*- line if
    enable-local-variables is nil.  I guess that this exception is
    unintentional.  If so, it is easy to fix.

I think that is a bug--please do fix it.

    Secondly, if I set enable-local-variables to 'ask and visit a file
    with a mode in the -*- line, and then answer twice no to the questions
    asking me whether I want to process local variables, then indeed no
    local variables are processed, _except_ for the mode in the -*- line.
    Is this intentional?

Yes.  Calling a mode function is not dangerous.
(The mode is not the same thing as a local variable.)

Why does it ask two questions instead of one?

Re: mode in -*- line

[Luc Teirlinck]

Richard Stallman wrote:

   Why does it ask two questions instead of one?

Because I both had a -*- line and a local variables list.  But that
was in a buffer I used for debugging and experimentation purposes.
In practice, such a situation may indeed very seldom occur.  So, in
practice, it may indeed only ask one question.

Sincerely,

Luc.

Re: mode in -*- line

[Luc Teirlinck]

Richard Stallman wrote:

       Firstly, if normal-mode is called interactively, it unconditionally
       processes all local variables in the -*- line and the local variables
       list _except_ that it ignores a mode in the -*- line if
       enable-local-variables is nil.  I guess that this exception is
       unintentional.  If so, it is easy to fix.

   I think that is a bug--please do fix it.

What about the following patch, which fixes the problem?  I can
install if desired.

===File ~/files-diff========================================
*** files.el	11 May 2005 15:00:33 -0500	1.766
--- files.el	11 May 2005 18:44:09 -0500	
***************
*** 1728,1737 ****
  in that case, this function acts as if `enable-local-variables' were t."
    (interactive)
    (or find-file (funcall (or default-major-mode 'fundamental-mode)))
!   (report-errors "File mode specification error: %s"
!     (set-auto-mode))
!   (report-errors "File local-variables error: %s"
!     (let ((enable-local-variables (or (not find-file) enable-local-variables)))
        (hack-local-variables)))
    (if (fboundp 'ucs-set-table-for-input) ; don't lose when building
        (ucs-set-table-for-input)))
--- 1728,1737 ----
  in that case, this function acts as if `enable-local-variables' were t."
    (interactive)
    (or find-file (funcall (or default-major-mode 'fundamental-mode)))
!   (let ((enable-local-variables (or (not find-file) enable-local-variables)))
!     (report-errors "File mode specification error: %s"
!       (set-auto-mode))
!     (report-errors "File local-variables error: %s"
        (hack-local-variables)))
    (if (fboundp 'ucs-set-table-for-input) ; don't lose when building
        (ucs-set-table-for-input)))
============================================================

Re: mode in -*- line

[Richard Stallman]

       I think that is a bug--please do fix it.

    What about the following patch, which fixes the problem?  I can
    install if desired.

It looks clean to me.