From: Alan M. <ac...@mu...> - 2008-06-01 17:00:45
|
Hi, Glenn, On Sat, May 31, 2008 at 06:51:35PM -0400, Glenn Morris wrote: > This applies in Emacs 22.2 and CVS trunk. > emacs -Q lib-src/etags.c > The local variables list in etags.c > contains values that may not be safe (*). > Do you want to apply it? You can type > y -- to apply the local variables list. > n -- to ignore the local variables list. > ! -- to apply the local variables list, and permanently mark these > values (*) as safe (in the future, they will be set automatically.) > indent-tabs-mode: t > tab-width: 8 > fill-column: 79 > * c-font-lock-extra-types: ("FILE" "bool" "language" "linebuffer" "fdesc" "node" "regexp") > c-file-style: "gnu" > If I answer `y', nothing happens. I have to press `y' a second time. Yes. This needs fixing, somehow. The way this happens is that in a C file's local variables list, there are two "special" variables, e.g. `c-file-style'. When c-basic-offset: 11 c-file-style: "k&r" occurs in the local variable list, this triggers a hook function which calls (c-set-style "k&r"). The hook is hack-local-variables-hook. The problem is that this c-set-style call will overwrite the explicit value for c-basic-offset. The explicit value MUST take precedence here. My solution was to call hack-local-variables a second time from within the hook function, first having deleted any occurrences of `mode', `c-file-style' etc. from the Local Variables. This kludge worked reasonably well until the handling of safe/dangerous-local-variables was changed for Emacs 22. Simply marking all pertinent variables as "safe" is not the right fix, because they aren't: some can contain arbitrary functions. Emacs doesn't really have the requisite hooks here: `before-hack-local-variables-hook' and `after-hack-local-variables-hook' would let the problem be fixed (rather than kludged), but it kind of feels like overkill. If Emacs were not to rebind the do-you-want-to-apply-it variable inside hack-local-variables, that would allow the kludge to work. Suggestions and helpful comments would be appreciated here. -- Alan Mackenzie (Nuremberg, Germany). |