GNU bug report logs -
#78693
14.0.9; Folding of math macros with a function spec is broken
Previous Next
Full log
Message #14 received at 78693 <at> debbugs.gnu.org (full text, mbox):
Hi Paul,
"Paul D. Nelson" <ultrono <at> 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
This bug report was last modified 2 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.