GNU bug report logs - #23827
25.1.50; tab-width file-local variable has no effect in etc/HELLO

Previous Next

Package: emacs;

Reported by: Eli Zaretskii <eliz <at> gnu.org>

Date: Wed, 22 Jun 2016 17:07:01 UTC

Severity: normal

Found in version 25.1.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #10 received at 23827 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: 23827 <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#23827: 25.1.50;
 tab-width file-local variable has no effect in etc/HELLO
Date: 24 Jun 2016 11:07:13 -0000
Hello, Eli.

In article <mailman.2018.1466615229.1216.bug-gnu-emacs <at> gnu.org> you wrote:
> From: eliz <at> HOME-C4E4A596F7.i-did-not-set--mail-host-address--so-tickle-me
> --text follows this line--
> To reproduce:

>   emacs -Q
>   C-h H

> Observe the messed-up alignment of the second column.  The reason is
> that the tab-width file-local variable setting didn't take effect;
> setting the variable by hand fixes the display.

> I suspect this change:

>   commit 26171e02773b9b2383f412dd79d241385d2d20df
>   Author: Alan Mackenzie <acm <at> muc.de>
>   Date:   Fri May 6 18:58:49 2016 +0000

>       Correct hack-local-variables change from Thu May 5 11:05:49 2016 +0000

>       Prevent hack-local-variables being called from the fundamental-mode mode call
>       early in normal-mode.  This fixes bug #23460 and bug #23463.

>       * lisp/files.el (normal-mode) Replace call to fundamental-mode with calls to
>       the things it calls, with the exception of hack-local-variables.

>       * etc/NEWS: Add an entry to note the calling of hack-local-variables at each
>       major mode initialization.

Yes.  That change (and the change it corrected) shifted the call of
`hack-local-variables' from the act of visiting a file, to the calling of
the major mode function.  Every major mode (including fundamental-mode)
calls `run-mode-hooks' which calls `hack-local-variables'.

However, the C function `set-buffer-major-mode', optimises the call to
`fundamental-mode' away, because that call previously didn't do anything.

(`set-buffer-major-mode' is the last fallback function which choses the
major mode when all other methods have been tried and failed in
`set-auto-mode'.)

So I propose to remove that special optimisation from
`set-buffer-major-mode', so that `fundamental-mode' actually gets called.
As an alternative, it would be possible to add special handling at the
Lisp level for `fundamental-mode', but I think that would be a worse fix.

Here's my proposed patch, which works:


diff --git a/src/buffer.c b/src/buffer.c
index b4b8304..8756cbb 100644
--- a/src/buffer.c
+++ b/src/buffer.c
@@ -1984,7 +1984,9 @@ the current buffer's major mode.  */)
 	function = BVAR (current_buffer, major_mode);
     }
 
-  if (NILP (function) || EQ (function, Qfundamental_mode))
+  if (NILP (function)) /* If function is `fundamental-mode', allow it to run
+                          so that `run-mode-hooks' and thus
+                          `hack-local-variables' get run. */
     return Qnil;
 
   count = SPECPDL_INDEX ();


What do you think?


> In GNU Emacs 25.1.50.166 (i686-pc-mingw32)
>  of 2016-06-22 built on HOME-C4E4A596F7
> Repository revision: cc113e557d56d849e9699ceb3bc4a735c628b46e
> Windowing system distributor 'Microsoft Corp.', version 5.1.2600
> Recent messages:
> For information about GNU Emacs and the GNU system, type C-h C-a.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).





This bug report was last modified 8 years and 213 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.