Hi Paul,
"Paul D. Nelson" <ultr...@gmail.com> writes:
> Here's a proposed solution that seems more robust to me. Recall that
> *macro*/*math* are lists consisting of items
>
> (SPEC (M1 M2 ...)),
>
> where SPEC is a display specification (an integer, a string or a
> function) and M1, M2, ... are macro names as strings. We could enhance
> the display specification to allow
>
> ((SPEC . SIG) (M1 M2 ...)),
>
> where SIG is a "signature" that restricts the number of args:
>
> - nil means no restriction,
>
> - an integer n means at most n total args (so 0 means unargumented), and
>
> - a cons cell (p . q) means at most p optional and q required args.
>
> With that enhancement, we could revert d0a57d8d and tag the defaults for
> LaTeX-fold-math-spec-list with "0", e.g.,
>
> ("∈" ("in")) -> (("∈" . 0) ("in"))
>
> That would fix the original "\in [0,1]" issue as well as the issue
> raised by Raghuzar. It would also make it easy to fix related issues,
> like the one with \mathbf noted above. Thoughts?
I like this proposal. It is backward compatible I think it should also
allow us to deal with optional arguments in a function spec. Currently
if the spec is a function it only receives the mandatory arguments. If
the number of arguments is part of the spec we can allow it to receive
up to p+q args without breaking existing code.
> Finally, I noticed that we've been CC'ing bug-auctex rather than the
> specific bug number, which is generating duplicated bugs at
> https://lists.gnu.org/archive/html/bug-auctex/2025-06/threads.html.
> I've tried to fix that here.
Thanks for catching this. I was surprised by emails about those new bugs.
Rahguzar
_______________________________________________
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex
