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

Previous Next

Package: auctex;

Reported by: Rahguzar <rahguzar <at> mailbox.org>

Date: Wed, 4 Jun 2025 17:41:01 UTC

Severity: normal

To reply to this bug, email your comments to 78696 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-auctex <at> gnu.org:
bug#78696; Package auctex. (Wed, 04 Jun 2025 17:41:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Rahguzar <rahguzar <at> mailbox.org>:
New bug report received and forwarded. Copy sent to bug-auctex <at> gnu.org. (Wed, 04 Jun 2025 17:41:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Rahguzar <rahguzar <at> mailbox.org>
To: "Paul D. Nelson" <ultrono <at> gmail.com>
Cc: bug-auctex <at> gnu.org
Subject: Re: 14.0.9; Folding of math macros with a function spec is broken
Date: Wed, 04 Jun 2025 22:40:13 +0500
Hi Paul,

"Paul D. Nelson" <ultrono <at> gmail.com> writes:

> Thanks Raghuzar.  The issue is the result of this change:
>
> --8<---------------cut here---------------start------------->8---
> diff --git a/tex-fold.el b/tex-fold.el
> index 766270ef..78e5b822 100644
> --- a/tex-fold.el
> +++ b/tex-fold.el
> @@ -901,6 +901,12 @@ TYPE can be either `env' for environments, `macro' for macros or
>             (goto-char (1+ start))
>             (LaTeX-find-matching-end)
>             (point))
> +          ((eq type 'math)
> +           (goto-char (1+ start))
> +           (if (zerop (skip-chars-forward "A-Za-z@"))
> +               (forward-char)
> +             (skip-chars-forward "*"))
> +           (point))
>            (t
>             (goto-char start)
>             (TeX-find-macro-end)))))
> --8<---------------cut here---------------end--------------->8---
>
> The intent here was that "math macros" built-in to tex-fold don't take
> arguments, but this is not the case for the custom one you provide.
>
>> (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?

> Paul




Information forwarded to bug-auctex <at> gnu.org:
bug#78696; Package auctex. (Wed, 04 Jun 2025 23:41:02 GMT) Full text and rfc822 format available.

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Paul D. Nelson" <ultrono <at> gmail.com>
To: Rahguzar <rahguzar <at> mailbox.org>
Cc: bug-auctex <at> gnu.org
Subject: Re: 14.0.9; Folding of math macros with a function spec is broken
Date: Thu, 05 Jun 2025 01:40:14 +0200
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.

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?

Paul




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.