[Top][All Lists]

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

Re: Extending TeX-read-key-val

From: Ikumi Keita
Subject: Re: Extending TeX-read-key-val
Date: Sun, 24 Oct 2021 01:47:15 +0900

Hi Arash,

>>>>> Arash Esbati <> writes:
> KEY-VAL-ALIST can be a variable name or an alist.  While it is
> sufficient for static key=vals, it is not easy for cases where vals can
> be dynamic, say for user defined colors and such.  This is the reason
> for some complexity in AUCTeX styles where values are added/deleted to
> buffer-local version key=vals (c.f. enumitem.el the function
> `LaTeX-enumitem-update-key-val-options' and hassle around
> `LaTeX-enumitem-key-val-options-local').  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, indicate in the prompt that we are
> reading an optional argument.  KEY-VAL-ALIST is an alist.  The
> car of each element should be a string representing a key and the
> optional cdr should be a list with strings to be used as values
> for the key.  KEY-VAL-ALIST can be a symbol or a function call
> returning an alist.  Use PROMPT as the prompt string."
>   (multi-prompt-key-value
>    (TeX-argument-prompt optional prompt "Options (k=v)")
>    (cond ((and (symbolp key-val-alist)
>              (boundp key-val-alist))
>         (eval key-val-alist t))
>        ((and (listp key-val-alist)
>              (symbolp (car key-val-alist))
>              (fboundp (car key-val-alist)))
>         (let ((head (car key-val-alist))
>               (tail (cdr key-val-alist)))
>           (apply head tail)))
>        (t
>         key-val-alist))))

> Then one could define a function returning up-to-date key-vals and use
> it in the style hook like this:
> (TeX-add-style-hook
>  "foo"
>  (lambda ()
>    (TeX-add-symbols
>     '("bar" (TeX-arg-key-val (function-returning-key-val))))))

It seems flexible and promising. I like this implementation.

Two minor points I noticed:
1. Maybe 
     (symbol-value key-val-alist)
   is more appropriate than
     (eval key-val-alist t)
   for its directness.
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 ..."?

Ikumi Keita

reply via email to

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