> Arash Esbati writes:
>> 2. "KEY-VAL-ALIST can be a symbol or a function call ..."
>> It seems that "function call" is a bit ambiguous to me. How about
>> "KEY-VAL-ALIST can be a variable or a function ..."?
> I wanted to express that something like this would not work:
> (TeX-add-style-hoo
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU AUCTeX".
The branch, master has been updated
via 9a42bf4787e4e951ae559442b8729d3cdba0c651 (commit)
from cd4a1c9154e686385
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU AUCTeX".
The branch, master has been updated
via 9a42bf4787e4e951ae559442b8729d3cdba0c651 (commit)
from cd4a1c9154e686385
Arash Esbati writes:
Hi Arash & Keita,
>> Two minor points I noticed:
>> 1. Maybe
>> (symbol-value key-val-alist)
>>is more appropriate than
>> (eval key-val-alist t)
>>for its directness.
>
> In general, you're right, but since we have turned on lexical binding in
> AUCTeX, w
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU AUCTeX".
The branch, master has been updated
via cd4a1c9154e68638560377bc13bfd244f2cf174d (commit)
from 2af20f478e675d48d
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU AUCTeX".
The branch, master has been updated
via cd4a1c9154e68638560377bc13bfd244f2cf174d (commit)
from 2af20f478e675d48d
Hi Keita,
Ikumi Keita writes:
>> Arash Esbati writes:
>> We could ease the situation if we change `TeX-read-key-val' to:
>> (defun TeX-read-key-val (optional key-val-alist &optional prompt)
>> "Prompt for keys and values in KEY-VAL-ALIST and return them.
>> If OPTIONAL is non-nil, indicat
