GNU bug report logs -
#78698
14.0.9; Folding of math macros with a function spec is broken
Previous Next
Full log
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
"Paul D. Nelson" <ultrono <at> gmail.com> 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
This bug report was last modified 3 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.