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

Previous Next

Full log

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

From: "Paul D. Nelson" <ultrono <at> gmail.com>
To: Rahguzar <rahguzar <at> mailbox.org>
Cc: 78693 <at> debbugs.gnu.org
Subject: Re: 14.0.9; Folding of math macros with a function spec is broken
Date: Mon, 23 Jun 2025 21:36:44 +0200

Hi Raghuzar,

Rahguzar <rahguzar <at> mailbox.org> writes:
> Something that is able to distinguish between
>
> \begin{theorem}[My favorite theorem]
>
> and 
>
> \begin{equation}
> [X,P]

By default, tex-fold.el folds theorem environments (taking into account
their optional captions) but not equation environments.  This happens
via the TeX-fold-macro-spec-list entries

    (TeX-fold-begin-display ("begin"))
    (TeX-fold-end-display ("end"))

and the TeX-fold-begin-end-spec-list entry for "theorem".

This approach would not correctly handle "equation" environments that
begin with commutator brackets, as you've noted, because the contains of
those brackets would be mistakenly consumed as if they were an optional
argument.

To treat such cases correctly, we could allow the signature (which with
the current version of the proposed patch can be an integer or pair of
integers, bounding the total or optional/required arguments) to be a
function.  In TeX-find-macro-end-helper, we could call that function to
determine whether any additional arguments should be consumed, passing
along any arguments found thus far.  We could assign the begin/end
macros a signature function that says "for \begin macros with
equation-like environments, don't accept any optional arguments".  This
would allow meaningful folding of both examples, without the artifact
you have noted.  On the other hand, it would require choosing good
defaults for which environments should not admit optional args, and I
don't have a clear sense there; do you?

In my own setup, I do not fold equation environments, but instead use
prettification, as described in my earlier email.  This serves as a
practical workaround.  Before I adopted it, I remember encountering the
same issue you described and using workarounds such as adding a blank
commented line before the commutator bracket.

Paul

Previous Next

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