GNU bug report logs -
#78752
31.0.50; New tex-mode prettify-symbols-mode rule causes visual regression
Previous Next
To reply to this bug, email your comments to 78752 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78752
; Package
emacs
.
(Tue, 10 Jun 2025 17:39:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Tony Zorman <mail <at> tony-zorman.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Tue, 10 Jun 2025 17:39:04 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi,
ever since ef6203b64aaf (Extend prettify-symbols-alist in TeX mode)
'tex--prettify-symbols-alist' contains the line
("\\ " . 9141) ; Literal ?⎵ breaks indentation
However, this is problematic and results in false positives for this
glyph, since it clashes with two literal backslashes -- which may be
used for line breaks -- followed by a space. For example,
\begin{align*}
f\colon A &\to B\\ a &\mapsto f(a)
\end{align*}
would display as
\begin{align*}
f: A &→ B\⎵a &↦ f(a)
\end{align*}
While I agree that a double backslash not followed by a newline is
confusing, some of my coauthors don't. This also affects other
environments that some people like to compress, like the ones for
matrices or TikZ pictures. I don't think getting this right is possible
without using regular expressions (which is AFAIU not how
'prettify-symbols-mode' works).
Tony
--
Tony Zorman | https://tony-zorman.com
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78752
; Package
emacs
.
(Tue, 10 Jun 2025 18:12:04 GMT)
Full text and
rfc822 format available.
Message #8 received at 78752 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Tony Zorman <mail <at> tony-zorman.com> writes:
> ever since ef6203b64aaf (Extend prettify-symbols-alist in TeX mode)
> 'tex--prettify-symbols-alist' contains the line
>
> ("\\ " . 9141) ; Literal ?⎵ breaks indentation
>
> However, this is problematic and results in false positives
> ...
> While I agree that a double backslash not followed by a newline is
> confusing, some of my coauthors don't
ef6203b64aaf was my attempt to share the less controversial
prettifications accumulated in my config, but I'm happy to "unshare"
this one (attached patch) if it's causing false positives.
Thanks, best,
Paul
[0001-Remove-literal-space-from-prettify-symbols-alist.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78752
; Package
emacs
.
(Wed, 11 Jun 2025 07:25:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 78752 <at> debbugs.gnu.org (full text, mbox):
Tony Zorman <mail <at> tony-zorman.com> writes:
>> ef6203b64aaf was my attempt to share the less controversial
>> prettifications accumulated in my config, but I'm happy to "unshare"
>> this one (attached patch) if it's causing false positives.
>
> I would personally prefer this, but can also obviously adjust my own
> config if needed
It's easier for users to add entries than to delete them, so I think
we're in agreement that the entry should be removed like in my patch.
> (this change certainly isn't as bad as the long established
> replacement of showing '\newline' as LINE SEPARATOR, making it
> essentially invisible by default).
I guess I haven't run into TeX \newline's often enough to notice this,
but it's invisible for me, too. @Tassilo: any thoughts on this one?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78752
; Package
emacs
.
(Wed, 11 Jun 2025 12:43:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 78752 <at> debbugs.gnu.org (full text, mbox):
> Cc: 78752 <at> debbugs.gnu.org, Tassilo Horn <tsdh <at> gnu.org>
> From: "Paul D. Nelson" <ultrono <at> gmail.com>
> Date: Wed, 11 Jun 2025 09:24:07 +0200
>
> Tony Zorman <mail <at> tony-zorman.com> writes:
>
> >> ef6203b64aaf was my attempt to share the less controversial
> >> prettifications accumulated in my config, but I'm happy to "unshare"
> >> this one (attached patch) if it's causing false positives.
> >
> > I would personally prefer this, but can also obviously adjust my own
> > config if needed
>
> It's easier for users to add entries than to delete them, so I think
> we're in agreement that the entry should be removed like in my patch.
>
> > (this change certainly isn't as bad as the long established
> > replacement of showing '\newline' as LINE SEPARATOR, making it
> > essentially invisible by default).
>
> I guess I haven't run into TeX \newline's often enough to notice this,
> but it's invisible for me, too. @Tassilo: any thoughts on this one?
The change seems like a no-brainer to me, but let's wait for Tassilo
to chime in.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78752
; Package
emacs
.
(Wed, 11 Jun 2025 14:01:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 78752 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> > (this change certainly isn't as bad as the long established
>> > replacement of showing '\newline' as LINE SEPARATOR, making it
>> > essentially invisible by default).
>>
>> I guess I haven't run into TeX \newline's often enough to notice
>> this, but it's invisible for me, too. @Tassilo: any thoughts on this
>> one?
>
> The change seems like a no-brainer to me, but let's wait for Tassilo
> to chime in.
It's 10 years ago since I added this and I cannot remember why I thought
it would be a good idea. It's certainly not. Feel free to remove it or
replace the LINE SEPARATOR with something line NEWLINE LEFT (⮒).
Bye,
Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78752
; Package
emacs
.
(Wed, 11 Jun 2025 14:12:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 78752 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
"Paul D. Nelson" <ultrono <at> gmail.com> writes:
> Tony Zorman <mail <at> tony-zorman.com> writes:
>
>> (this change certainly isn't as bad as the long established
>> replacement of showing '\newline' as LINE SEPARATOR, making it
>> essentially invisible by default).
>
> I guess I haven't run into TeX \newline's often enough to notice this,
> but it's invisible for me, too. @Tassilo: any thoughts on this one?
I'm not Tassilo, but my suggestion is to remove the entries for '\newline'
and '\ ' from the prettification-list. Consider this piece of valid
LaTeX-code:
--8<---------------cut here---------------start------------->8---
\_%
\begin{tabular}[t]{p{5cm}l}
foo\newline bar & baz
\end{tabular}
\_
\_\parbox[t]{5cm}{Term-\\ S.}\_
\_\parbox[t]{5cm}{Term-\\S.}\_
--8<---------------cut here---------------end--------------->8---
which is prettified to this:
[pretty-symbols.png (image/png, inline)]
[Message part 3 (text/plain, inline)]
\newline is effectively gone, and what happens after \\ is also wrong.
I'm not sure, but I think the \parbox examples above show a bug in
`tex--prettify-symbols-compose-p' which should also check if the
character(s) before the currently ignored START is(are) backslashes, and
if yes, how many, and then prettify or not. AUCTeX has this for this
purpose:
--8<---------------cut here---------------start------------->8---
(defun TeX-escaped-p (&optional pos)
"Return t if the character at position POS is escaped.
If POS is omitted, examine the character at point.
A character is escaped if it is preceded by an odd number of
escape characters, such as \"\\\" in LaTeX."
(save-excursion
(when pos (goto-char pos))
(not (zerop (mod (skip-chars-backward (regexp-quote TeX-esc)) 2)))))
--8<---------------cut here---------------end--------------->8---
I'm Cc'ing Stefan M. who maintains tex-mode.el.
Best, Arash
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78752
; Package
emacs
.
(Wed, 11 Jun 2025 14:55:04 GMT)
Full text and
rfc822 format available.
Message #23 received at 78752 <at> debbugs.gnu.org (full text, mbox):
On Tue, Jun 10 2025 20:11, Paul D. Nelson wrote:
> Tony Zorman <mail <at> tony-zorman.com> writes:
>> ever since ef6203b64aaf (Extend prettify-symbols-alist in TeX mode)
>> 'tex--prettify-symbols-alist' contains the line
>>
>> ("\\ " . 9141) ; Literal ?⎵ breaks indentation
>>
>> However, this is problematic and results in false positives
>> ...
>> While I agree that a double backslash not followed by a newline is
>> confusing, some of my coauthors don't
>
> ef6203b64aaf was my attempt to share the less controversial
> prettifications accumulated in my config, but I'm happy to "unshare"
> this one (attached patch) if it's causing false positives.
I would personally prefer this, but can also obviously adjust my own
config if needed (this change certainly isn't as bad as the long
established replacement of showing '\newline' as LINE SEPARATOR, making
it essentially invisible by default).
I'm a big fan of most of the other additions, btw, so thanks!
Tony
--
Tony Zorman | https://tony-zorman.com
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.