[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#21529: 2015-09-20; Xemacs, auctex git, cannot run latex,pdflatexx

From: Mosè Giordano
Subject: bug#21529: 2015-09-20; Xemacs, auctex git, cannot run latex,pdflatexx
Date: Tue, 22 Sep 2015 11:11:08 +0200

Hi Tassilo,

2015-09-22 8:37 GMT+02:00 Tassilo Horn <address@hidden>:
> Uwe Brauer <address@hidden> 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.

Yes, in general I agree that someone may want to remove an entry from
a list, but in this particular case I don't see why one should want to
do that, this would cause only problems.  Overriding a default
expander is fine instead.

> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]