Subject: Re: 14.0.9; Folding of math macros with a function spec is broken

From: Rahguzar <[email-masked]>
Date: Thu, 05 Jun 2025 08:54:26 +0500

"Paul D. Nelson" <[email-masked]> writes:

> Hi Rahguzar,
>
>>>> (setq TeX-fold-math-spec-list `((,(lambda (text) (propertize text 'face '(underline))) ("underline"))))
>>>
>>> Is there a reason to prefer this vs. the same with
>>> TeX-fold-macro-spec-list in place of TeX-fold-math-spec-list?
>>
>> The reason for why it is in TeX-fold-math-spec-list is that when I
>> started with Emacs I stole it from Tecosaur's config. There are quite a
>> few function specs in my TeX-fold-math-spec-list e.g. for sqrt, frac,
>> mathcal, mathfrak and mathbb etc and most of them are relevant only for
>> math. Should they be moved to TeX-fold-macro-spec-list?
>
> I think one can use TeX-fold-macro-spec-list for all of these.  In
> particular, your underline example works fine there for me.
>
> It's not clear to me from those what exactly are the intended purposes
> of the various spec lists (macro/env/math).  My impression from the
> built-in examples was that the math list is for macros like "alpha" that
> accept no arguments.

Yes, it would be good to make this clear in the documentation.

> The motivation for the offending patch was to make it so folding "\in
> [0, 1]" doesn't hide the "[0, 1]" as if it were an optional arg.  To
> give a more robust fix that works with your code sample, we would need a
> more robust way to detect when a macro is not intended to have any
> (optional) arguments.  The implemented approach was to just assume that
> all the "math" macros accept no arguments.  Do you or does anyone have
> other suggestions?

I have also seen the problem you are encountering so it is good to
have a fix for that.

I think to preserve breakage and preserve backward compatibility it
would be better to either:

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.

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

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

> Paul

Rahguzar