GNU bug report logs - #78693
14.0.9; Folding of math macros with a function spec is broken

Previous Next

Full log

View this message in rfc822 format

From: "Paul D. Nelson" <ultrono <at> gmail.com>
To: Rahguzar <rahguzar <at> mailbox.org>
Cc: 78693 <at> debbugs.gnu.org
Subject: bug#78693: 14.0.9; Folding of math macros with a function spec is broken
Date: Fri, 06 Jun 2025 11:39:03 +0200

Hi Raghuzar, thanks for your suggestions.

Regarding (1) and (2), I searched my shared tex projects and found
examples that those approaches would not fold correctly:

> 1) Assume that there is no white-space between the macro name and the
> brackets enclosing the arguments. This is probably not how TeX syntax
> works but I think (not too sure about this) it is the usual style. This
> behavior can be controlled by a custom variable.

"\in[0,1]"

I also worry that style like

  \includegraphics
    [width=0.8\textwidth]
    {result.pdf}

is not too uncommon.

> 2) Since the problem is with optional arguments we can allow { after the
> macro name but not [.

"\in{\rm SL}_2"

> 3) Another option can be to introduce a new spec alist for macros
> without optional args.

Maybe call it TeX-fold-unargumented-spec-list.  Then, we would have:

TeX-fold-macro-spec-list
TeX-fold-math-spec-list
TeX-fold-env-spec-list
TeX-fold-unargumented-spec-list

The defaults for *math* would move to *unargumented* and *macro*/*math*
would behave identically.  This seems a bit complicated.

Moreover, none of the above solutions address related (but rarer) issues
with argumented macros.  For instance, if one includes \mathbf in
*macro*/*math*, then the following folds incorrectly:

  $\mathbf{text} [0,1]$

(I feel like I've seen similar examples occur organically over the
years, but can't quickly think of one.)

----------------------------------------------------------------------

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 also thought I'd link the original proposal [1] for TeX-fold
math-spec-list.  My reading is that the purpose of the *macro*/*math*
split was just to better organize the defaults.

[1]
https://lists.gnu.org/archive/html/auctex-devel/2007-01/msg00078.html

----------------------------------------------------------------------

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.