GNU bug report logs - #21529
2015-09-20; Xemacs, auctex git, cannot run latex,pdflatex

Previous Next

Full log

View this message in rfc822 format

From: Tassilo Horn <tsdh <at> gnu.org>
To: Uwe Brauer <oub <at> mat.ucm.es>
Cc: "21529 <at> debbugs.gnu.org" <21529 <at> debbugs.gnu.org>, Mosè Giordano <mose <at> gnu.org>
Subject: bug#21529: 2015-09-20; Xemacs, auctex git, cannot run latex,pdflatexx
Date: Tue, 22 Sep 2015 08:37:03 +0200

Uwe Brauer <oub <at> mat.ucm.es> writes:

>    > This entry is there by default, you must have set
>    > `TeX-expand-list' somewhere.
>
> I think what happens is this: I have TeX-expand-list customized and
> emacs copies all its values into, in my case, custom-init.el and saves
> the changes I did. So if a new variable is added to that list it seems
> that the list in custom-init.el «blocks» the new feature. At least for
> Xemacs why this does not happen in GNU I do not know.

I think it's the same there.  The customization facility sets variables,
thus it is simply not really good for variables whose default value is a
non-empty list.  I think we could use a :set property function to handle
these situation where the function wouldn't actually set the value but
just add to it, e.g., using `push' or `pushnew'.  But then the problem
would be that the user wouldn't have a chance to remove entries from
such variables.  Well, in the case of `TeX-expand-list' he could add
do-nothing entries to override the default ones, I guess.

Another approach with the same limitations would be that we add a
variable `TeX-expand-list-builtin' with all the current default
expansions and leave `TeX-expand-list' to the user.

I think we should probably do the latter because we use that approach
for several other variables already.

Bye,
Tassilo

Previous Next

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