bug-auctex
[Top][All Lists]
Advanced

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

bug#20513: 11.88.5; TeX-view-program-list generated in wrong format by C


From: Mosè Giordano
Subject: bug#20513: 11.88.5; TeX-view-program-list generated in wrong format by Customize
Date: Thu, 7 May 2015 12:36:35 +0200

2015-05-07 11:03 GMT+02:00 David Kastrup <address@hidden>:
> Tassilo Horn <address@hidden> writes:
>
>> Mosè Giordano <address@hidden> writes:
>>
>>> I agree, but I confirm `TeX-view-program-list' is built in the wrong
>>> way when changed with customize interface, as reported by Дарио.  It
>>> worked as expected before commit
>>>
>>>   * 59ccf34 (2014-11-28) Check the viewer executable exists before
>>> opening it.
>>>
>>> where the customization type of the variable was changed from an alist
>>> to a repeated list, but the command part of the type hasn't been
>>> modified.  How should it be fixed?
>>
>> I think the problem is that the command part is a group of a choice
>> where one choice is a list again.  A group is a list, and list is a
>> list, so command parts will result in ((stuff)) where it should be just
>> (stuff).  So can't you simply remove the outer
>>
>>   (group :tag "Command parts"
>>
>> and that's it?
>
> I seem to remember that there is some option in the customization
> definition where some group will be folded into the surrounding list.
>
> Ah yes, (info "(elisp) Splicing into Lists").
>
> File: elisp.info,  Node: Splicing into Lists,  Next: Type Keywords,  Prev: 
> Composite Types,  Up: Customization Types
>
> 14.4.3 Splicing into Lists
> --------------------------
>
> The ‘:inline’ feature lets you splice a variable number of elements into
> the middle of a ‘list’ or ‘vector’ customization type.  You use it by
> adding ‘:inline t’ to a type specification which is contained in a
> ‘list’ or ‘vector’ specification.
>
>    Normally, each entry in a ‘list’ or ‘vector’ type specification
> describes a single element type.  But when an entry contains ‘:inline
> t’, the value it matches is merged directly into the containing
> sequence.  For example, if the entry matches a list with three elements,
> those become three elements of the overall sequence.  This is analogous
> to ‘,@’ in a backquote construct (*note Backquote::).

Thanks to both, the bug should be fixed now.

Bye,
Mosè





reply via email to

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