GNU bug report logs - #78752
31.0.50; New tex-mode prettify-symbols-mode rule causes visual regression

Previous Next

Package: emacs;

Reported by: Tony Zorman <mail <at> tony-zorman.com>

Date: Tue, 10 Jun 2025 17:39:03 UTC

Severity: normal

Found in version 31.0.50

To reply to this bug, email your comments to 78752 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-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):

From: Tony Zorman <mail <at> tony-zorman.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; New tex-mode prettify-symbols-mode rule causes visual
 regression
Date: Tue, 10 Jun 2025 18:39:37 +0200
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):

From: "Paul D. Nelson" <ultrono <at> gmail.com>
To: Tony Zorman <mail <at> tony-zorman.com>
Cc: 78752 <at> debbugs.gnu.org
Subject: Re: bug#78752: 31.0.50; New tex-mode prettify-symbols-mode rule causes
 visual regression
Date: Tue, 10 Jun 2025 20:11:18 +0200
[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):

From: "Paul D. Nelson" <ultrono <at> gmail.com>
To: Tony Zorman <mail <at> tony-zorman.com>
Cc: 78752 <at> debbugs.gnu.org, Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#78752: 31.0.50; New tex-mode prettify-symbols-mode rule
 causes visual regression
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?




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):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Paul D. Nelson" <ultrono <at> gmail.com>, tsdh <at> gnu.org
Cc: mail <at> tony-zorman.com, 78752 <at> debbugs.gnu.org
Subject: Re: bug#78752: 31.0.50;
 New tex-mode prettify-symbols-mode rule causes visual regression
Date: Wed, 11 Jun 2025 15:42:20 +0300
> 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):

From: Tassilo Horn <tsdh <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: mail <at> tony-zorman.com, 78752 <at> debbugs.gnu.org,
 "Paul D. Nelson" <ultrono <at> gmail.com>
Subject: Re: bug#78752: 31.0.50; New tex-mode prettify-symbols-mode rule
 causes visual regression
Date: Wed, 11 Jun 2025 15:59:58 +0200
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):

From: Arash Esbati <arash <at> gnu.org>
To: "Paul D. Nelson" <ultrono <at> gmail.com>
Cc: Tony Zorman <mail <at> tony-zorman.com>, 78752 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#78752: 31.0.50; New tex-mode prettify-symbols-mode rule
 causes visual regression
Date: Wed, 11 Jun 2025 16:11:35 +0200
[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):

From: Tony Zorman <mail <at> tony-zorman.com>
To: "Paul D. Nelson" <ultrono <at> gmail.com>
Cc: 78752 <at> debbugs.gnu.org
Subject: Re: bug#78752: 31.0.50; New tex-mode prettify-symbols-mode rule
 causes visual regression
Date: Tue, 10 Jun 2025 22:04:31 +0200
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.