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.
_______________________________________________
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex
