GNU bug report logs - #25564
11.90; XEmacs lacks file-local-variables-alist and reports error.

Previous Next

Package: auctex;

Reported by: Ikumi Keita <ikumi <at> ikumi.que.jp>

Date: Sat, 28 Jan 2017 16:11:01 UTC

Severity: normal

Found in version 11.90

Done: Tassilo Horn <tsdh <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


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

From: Tassilo Horn <tsdh <at> gnu.org>
To: Mosè Giordano <mose <at> gnu.org>
Cc: Ikumi Keita <ikumi <at> ikumi.que.jp>, 25564 <at> debbugs.gnu.org
Subject: Re: bug#25564: 11.90;
 XEmacs lacks file-local-variables-alist and reports error.
Date: Wed, 01 Feb 2017 19:12:50 +0100
Mosè Giordano <mose <at> gnu.org> writes:

Hi Mosè & Ikumi,

>> Do you know if XEmacs has some similar feature, i.e., a way to check
>> which variables have been set using file (or directory) local
>> variables?
>
> If you want to check whether a variable was set locally in a
> XEmacs-compatible way you can use:
>
>     (local-variable-p 'variable-name (current-buffer))
>
> This is what is done in style/biblatex.el ;-)

No, that won't help here.  I need to know where that local binding came
from.  The reason is `LaTeX-verbatim-environments-local' and friends are
always buffer-local.  Styles like minted or lstlistings add to those
lists to make font-latex aware of the fact that, e.g., clojurecode, is a
verbatim environment generated by minted and should be highlighted as
such.  When such a style is loaded, a font-lock refresh is triggered to
put that into effect.

However, a user might also have

% Local Variables:
% LaTeX-verbatim-environments-local: ("mycode")
% End:

and the new function added to `hack-local-variables-hook' will then also
trigger a font-lock refresh.

Well, maybe we could rely that `hack-local-variables-hook' is always
executed before styles are applied (when finding a TeX file or running
`TeX-normal-mode').  In that case, if any of these variables in question
do have a local non-nil binding, then we trigger a font-lock refresh.
So we might trigger it too often but I guess that's acceptable.

Ikumi, I'll implement that now.  Could you please check if it works as
expected in the coming days?

Bye,
Tassilo




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

Previous Next


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