GNU bug report logs - #77381
[PATCH] extend tex--prettify-symbols-alist

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 77381 in the body.
You can then email your comments to 77381 AT debbugs.gnu.org in the normal way.

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

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

From: "Paul D. Nelson" <ultrono <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] extend tex--prettify-symbols-alist
Date: Sun, 30 Mar 2025 13:41:05 +0200

[Message part 1 (text/plain, inline)]

This patch adds symbols to tex--prettify-symbols-alist.  The new symbols
include math symbols, accented characters, quotes and fractions.

[0001-Extend-tex-prettify-symbols-alist.patch (text/x-patch, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Paul D. Nelson" <ultrono <at> gmail.com>
Cc: 77381 <at> debbugs.gnu.org
Subject: Re: bug#77381: [PATCH] extend tex--prettify-symbols-alist
Date: Sun, 30 Mar 2025 14:54:06 +0300

> From: "Paul D. Nelson" <ultrono <at> gmail.com>
> Date: Sun, 30 Mar 2025 13:41:05 +0200
> 
> This patch adds symbols to tex--prettify-symbols-alist.  The new symbols
> include math symbols, accented characters, quotes and fractions.

Thanks, but did you make sure this won't cause any regressions and/or
annoyances if the user's machine doesn't have the requisite fonts
installed?

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

From: "Paul D. Nelson" <ultrono <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77381 <at> debbugs.gnu.org
Subject: Re: bug#77381: [PATCH] extend tex--prettify-symbols-alist
Date: Sun, 30 Mar 2025 15:27:05 +0200

>> This patch adds symbols to tex--prettify-symbols-alist.  The new symbols
>> include math symbols, accented characters, quotes and fractions.
>
> Thanks, but did you make sure this won't cause any regressions and/or
> annoyances if the user's machine doesn't have the requisite fonts
> installed?

If I understand correctly, the concern is that if a font for a character
in the alist is unavailable, Emacs will display a white square.  For
instance, on my machine (running macOS), adding

  (add-to-list 'prettify-symbols-alist '("\\satellite" . #x1F6F0))

makes "\satellite" look like a white square when prettify-symbols-mode
is active.

So the question is whether the symbols introduced by this patch are more
likely to cause such issues than those already in
tex--prettify-symbols-alist.

Using (set-face-attribute 'default nil :font "...") and C-u C-x =, I
checked that DejaVu Sans supplies all the new symbols except those
attached to

  \bigsqcup, \biguplus, "\ "

which are found in DejaVu Math TeX Gyre.

I checked that Arial has all the new symbols except those attached to

- \frac{1}{7}, \frac{1}{9}, \frac{1}{10}, \Game, found in DejaVu Sans
  (like for \daleth).

- \Finv, found in American Typewriter (like for \cdot), and

- \bigodot, \bigoplus, \bigotimes, \bigsqcup, \biguplus, \iiiint, found
  in DejaVu Math TeX Gyre.

Helvetica lacks many of the newly added and already present symbols.

This was a spot check, but it suggests that the new entries have similar
fallback behavior to existing ones, with the exception of a few
characters that depend on DejaVu Math TeX Gyre.

Perhaps the simplest way to avoid regressions would be to drop those
less well-supported symbols?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Paul D. Nelson" <ultrono <at> gmail.com>
Cc: 77381 <at> debbugs.gnu.org
Subject: Re: bug#77381: [PATCH] extend tex--prettify-symbols-alist
Date: Sun, 30 Mar 2025 17:33:19 +0300

> From: "Paul D. Nelson" <ultrono <at> gmail.com>
> Cc: 77381 <at> debbugs.gnu.org
> Date: Sun, 30 Mar 2025 15:27:05 +0200
> 
> >> This patch adds symbols to tex--prettify-symbols-alist.  The new symbols
> >> include math symbols, accented characters, quotes and fractions.
> >
> > Thanks, but did you make sure this won't cause any regressions and/or
> > annoyances if the user's machine doesn't have the requisite fonts
> > installed?
> 
> If I understand correctly, the concern is that if a font for a character
> in the alist is unavailable, Emacs will display a white square.  For
> instance, on my machine (running macOS), adding
> 
>   (add-to-list 'prettify-symbols-alist '("\\satellite" . #x1F6F0))
> 
> makes "\satellite" look like a white square when prettify-symbols-mode
> is active.

That's what I was afraid of.

> So the question is whether the symbols introduced by this patch are more
> likely to cause such issues than those already in
> tex--prettify-symbols-alist.
> 
> Using (set-face-attribute 'default nil :font "...") and C-u C-x =, I
> checked that DejaVu Sans supplies all the new symbols except those
> attached to
> 
>   \bigsqcup, \biguplus, "\ "
> 
> which are found in DejaVu Math TeX Gyre.
> 
> I checked that Arial has all the new symbols except those attached to
> 
> - \frac{1}{7}, \frac{1}{9}, \frac{1}{10}, \Game, found in DejaVu Sans
>   (like for \daleth).
> 
> - \Finv, found in American Typewriter (like for \cdot), and
> 
> - \bigodot, \bigoplus, \bigotimes, \bigsqcup, \biguplus, \iiiint, found
>   in DejaVu Math TeX Gyre.
> 
> Helvetica lacks many of the newly added and already present symbols.
> 
> This was a spot check, but it suggests that the new entries have similar
> fallback behavior to existing ones, with the exception of a few
> characters that depend on DejaVu Math TeX Gyre.
> 
> Perhaps the simplest way to avoid regressions would be to drop those
> less well-supported symbols?

Ideally, we should only add those which can be displayed.  The
function char-displayable-p should be able to tell.  Would it be
possible to change the code such that only the symbols that pass that
test are added?

Thanks.

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

From: "Paul D. Nelson" <ultrono <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77381 <at> debbugs.gnu.org
Subject: Re: bug#77381: [PATCH] extend tex--prettify-symbols-alist
Date: Sun, 30 Mar 2025 18:21:44 +0200

> Ideally, we should only add those which can be displayed.  The
> function char-displayable-p should be able to tell.  Would it be
> possible to change the code such that only the symbols that pass that
> test are added?

I tried, but wasn't able to extract the necessary information from
char-displayable-p:

In GUI Emacs,

  (char-displayable-p #x1F6F0) -> 'unicode

and that character is not displayable for me (it renders as a white
square).

In Emacs -nw,

  (char-displayable-p #x1d550) -> 'unicode

but that character displays normally for me.

Thus, when the return value of char-displayable-p is 'unicode, I don't
know how to determine whether the character would be displayable for our
purposes (i.e., not as a white square).

Any suggestions?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Paul D. Nelson" <ultrono <at> gmail.com>
Cc: 77381 <at> debbugs.gnu.org
Subject: Re: bug#77381: [PATCH] extend tex--prettify-symbols-alist
Date: Sun, 30 Mar 2025 19:50:38 +0300

> From: "Paul D. Nelson" <ultrono <at> gmail.com>
> Cc: 77381 <at> debbugs.gnu.org
> Date: Sun, 30 Mar 2025 18:21:44 +0200
> 
> > Ideally, we should only add those which can be displayed.  The
> > function char-displayable-p should be able to tell.  Would it be
> > possible to change the code such that only the symbols that pass that
> > test are added?
> 
> I tried, but wasn't able to extract the necessary information from
> char-displayable-p:
> 
> In GUI Emacs,
> 
>   (char-displayable-p #x1F6F0) -> 'unicode
> 
> and that character is not displayable for me (it renders as a white
> square).
> 
> In Emacs -nw,
> 
>   (char-displayable-p #x1d550) -> 'unicode
> 
> but that character displays normally for me.

For a GUI frame, if char-displayable-p returns a symbol, the character
is not displayable.  Characters that can be displayed on a GUI frame
should cause char-displayable-p to return a string, the name of the
font suitable for the character.

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

From: "Paul D. Nelson" <ultrono <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77381 <at> debbugs.gnu.org
Subject: Re: bug#77381: [PATCH] extend tex--prettify-symbols-alist
Date: Sun, 30 Mar 2025 19:47:47 +0200

[Message part 1 (text/plain, inline)]

>> > Ideally, we should only add those which can be displayed.  The
>> > function char-displayable-p should be able to tell.  Would it be
>> > possible to change the code such that only the symbols that pass that
>> > test are added?
>> 
>> (...)
>
> For a GUI frame, if char-displayable-p returns a symbol, the character
> is not displayable.  Characters that can be displayed on a GUI frame
> should cause char-displayable-p to return a string, the name of the
> font suitable for the character.

Thanks.  With the attached patch, prettify-symbols-mode filters
prettify-symbols-alist to those entries that are displayable in the
following sense:

  (let ((display-capability (char-displayable-p char)))
    (if (display-graphic-p)
        (or (eq display-capability t)
            (fontp display-capability))
      display-capability))

I've tested it in tex-mode, with GUI and terminal Emacs, using the
examples from this thread.  Any feedback or other suggestions would be
welcome.

[0001-Restrict-symbol-prettification-to-displayable-ones.patch (text/x-patch, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Paul D. Nelson" <ultrono <at> gmail.com>
Cc: 77381 <at> debbugs.gnu.org
Subject: Re: bug#77381: [PATCH] extend tex--prettify-symbols-alist
Date: Sun, 30 Mar 2025 21:42:27 +0300

> From: "Paul D. Nelson" <ultrono <at> gmail.com>
> Cc: 77381 <at> debbugs.gnu.org
> Date: Sun, 30 Mar 2025 19:47:47 +0200
> 
> +(defun prettify-symbols--char-displayable-p (char)
> +  "Return non-nil if CHAR can be displayed with the current font.
> +A character is considered displayable:
> +
> +- on a graphical display, if `char-displayable-p' returns either t or a
> +  font object, and
> +
> +- on a non-graphical display, if `char-displayable-p' returns non-nil."
> +  (let ((display-capability (char-displayable-p char)))
> +    (if (display-graphic-p)
> +        (or (eq display-capability t)
> +            (fontp display-capability))
> +      display-capability)))

I think this function should be in mule.el (under a different name),
and it should accept a frame as an additional argument, for which to
call display-graphic-p.

Otherwise, LGTM, thanks.

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

From: "Paul D. Nelson" <ultrono <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77381 <at> debbugs.gnu.org
Subject: Re: bug#77381: [PATCH] extend tex--prettify-symbols-alist
Date: Sun, 30 Mar 2025 21:21:41 +0200

[Message part 1 (text/plain, inline)]

> I think this function should be in mule.el (under a different name),
> and it should accept a frame as an additional argument, for which to
> call display-graphic-p.
>
> Otherwise, LGTM, thanks.

Thanks, please see attached.

[Message part 2 (text/x-patch, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Paul D. Nelson" <ultrono <at> gmail.com>
Cc: 77381 <at> debbugs.gnu.org
Subject: Re: bug#77381: [PATCH] extend tex--prettify-symbols-alist
Date: Mon, 31 Mar 2025 15:46:17 +0300

> From: "Paul D. Nelson" <ultrono <at> gmail.com>
> Cc: 77381 <at> debbugs.gnu.org
> Date: Sun, 30 Mar 2025 21:21:41 +0200
> 
> > I think this function should be in mule.el (under a different name),
> > and it should accept a frame as an additional argument, for which to
> > call display-graphic-p.
> >
> > Otherwise, LGTM, thanks.
> 
> Thanks, please see attached.

Some minor comments:

> +(defun char-graphically-displayable-p (char &optional frame)

I prefer char-displayable-on-frame-p (since "graphically might be
interpreted as meaning only GUI frames).

> +  "Return non-nil if CHAR can be graphically displayed in FRAME.
> +FRAME nil or omitted means use the selected frame.
> +
> +This function provides a more reliable test than `char-displayable-p'
> +for determining if a character will display properly.

"More reliable" will cause people wonder why we have "unreliable"
APIs.  But the essence is not the reliability, the essence is
accuracy: char-displayable-p returns the ability of the entire Emacs
session, whereas this new function returns the ability of a particular
frame.

I also think this function should be documented in the ELisp manual
and in NEWS, but that could be a separate patch.

Thanks.

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

From: Arash Esbati <arash <at> gnu.org>
To: "Paul D. Nelson" <ultrono <at> gmail.com>
Cc: 77381 <at> debbugs.gnu.org
Subject: Re: bug#77381: [PATCH] extend tex--prettify-symbols-alist
Date: Mon, 31 Mar 2025 19:58:44 +0200

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

> This patch adds symbols to tex--prettify-symbols-alist.  The new symbols
> include math symbols, accented characters, quotes and fractions.
>
> From 7c9d1dea0e9b4b7b61df3c60b05badca11aa24bc Mon Sep 17 00:00:00 2001
> From: Paul Nelson <ultrono <at> gmail.com>
> Date: Sun, 30 Mar 2025 13:31:58 +0200
> Subject: [PATCH] Extend tex--prettify-symbols-alist
>
> * lisp/textmodes/tex-mode.el (tex--prettify-symbols-alist): Add
> further math symbols, accented characters, quotes and fractions.
> ---
>  lisp/textmodes/tex-mode.el | 183 +++++++++++++++++++++++++++++++++++--
>  1 file changed, 176 insertions(+), 7 deletions(-)
>
> diff --git a/lisp/textmodes/tex-mode.el b/lisp/textmodes/tex-mode.el
> index ad1d4fa1f88..73f634b7282 100644
> --- a/lisp/textmodes/tex-mode.el
> +++ b/lisp/textmodes/tex-mode.el
> +    ;; Accented characters
> +    ("{\\'a}" . ?á)
> +    ("{\\'e}" . ?é)
> +    ("{\\'i}" . ?í)
> +    ("{\\'o}" . ?ó)
> +    ("{\\'u}" . ?ú)
> +    ("{\\'A}" . ?Á)

Hi Paul,

I suggest to drop this part.  This notation kills kerning (due to
braces) and hyphenation when characters are constructed.  The modern way
is to use a font which contains these chars (e.g., lmodern), set the
buffer encoding to UTF-8 and just enter the char.  UTF-8 is standard for
LaTeX input since April 2018.  I admit, this is LaTeX and not plain TeX,
but `tex--prettify-symbols-alist' deals mostly with LaTeX.

Best, Arash

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

From: "Paul D. Nelson" <ultrono <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77381 <at> debbugs.gnu.org
Subject: Re: bug#77381: [PATCH] extend tex--prettify-symbols-alist
Date: Mon, 31 Mar 2025 22:33:59 +0200

[Message part 1 (text/plain, inline)]

>> +(defun char-graphically-displayable-p (char &optional frame)
>
> I prefer char-displayable-on-frame-p (since "graphically might be
> interpreted as meaning only GUI frames).
>
>> +  "Return non-nil if CHAR can be graphically displayed in FRAME.
>> +FRAME nil or omitted means use the selected frame.
>> +
>> +This function provides a more reliable test than `char-displayable-p'
>> +for determining if a character will display properly.
>
> "More reliable" will cause people wonder why we have "unreliable"
> APIs.  But the essence is not the reliability, the essence is
> accuracy: char-displayable-p returns the ability of the entire Emacs
> session, whereas this new function returns the ability of a particular
> frame.
>
> I also think this function should be documented in the ELisp manual
> and in NEWS, but that could be a separate patch.

Thanks for pushing for clarity on this.

One thing I realized is that the implementation I had given of the new
function was incorrect in its handling of the frame argument, because
the function char-displayable-p does seem to depend upon the selected
frame (e.g., on a graphical terminal with multiple frames, each having
their own default face or font-backend).

Assuming I haven't misunderstood, I saw a few options for correcting the
new function:

1. Wrap char-displayable-p in (with-selected-frame ...).

2. Give char-displayable-p a frame argument, and wrap its body in
   (with-selected-frame ...).

3. Drop the frame argument altogether (leaving (with-selected-frame
   ...) to callers of these functions).

Option (3) seemed simplest to me, and also at the least risk of
introducing confusion concerning the name of the new function: at a
glance, "char-displayable-on-frame-p" might suggest incorrectly that it
does the analogue for the given frame of what char-displayable-p does
for the selected frame.  I went with (3) for now, but would be happy to
adjust if desired.  Please see attached.

[0001-Restrict-symbol-prettification-to-displayable-ones.patch (text/x-patch, attachment)]

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

From: "Paul D. Nelson" <ultrono <at> gmail.com>
To: Arash Esbati <arash <at> gnu.org>
Cc: 77381 <at> debbugs.gnu.org
Subject: Re: bug#77381: [PATCH] extend tex--prettify-symbols-alist
Date: Mon, 31 Mar 2025 22:38:39 +0200

[Message part 1 (text/plain, inline)]

Hi Arash, 

Thanks for your feedback concerning the accented characters --
I had no idea one could do this in "modern" (La)TeX.  Please find
attached the updated patch.  Any further feedback would be welcome.

Paul

[0001-Extend-tex-prettify-symbols-alist.patch (text/x-patch, attachment)]

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

From: Arash Esbati <arash <at> gnu.org>
To: "Paul D. Nelson" <ultrono <at> gmail.com>
Cc: 77381 <at> debbugs.gnu.org
Subject: Re: bug#77381: [PATCH] extend tex--prettify-symbols-alist
Date: Mon, 31 Mar 2025 23:09:14 +0200

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

> Thanks for your feedback concerning the accented characters --
> I had no idea one could do this in "modern" (La)TeX.

This was possible with LaTeX basically since forever, you need something
this in your preamble:

\usepackage[utf8]{inputenc}
\usepackage{lmodern}% or any other font
\usepackage[T1]{fontenc}

Since April 2018, you can drop the inputenc thing.  The other challenge
was to find a font which covers the characters you need, and then assign
the correct encoding to it via fontenc.  With the advent of XeTeX and
LuaTeX, you can drop the fontenc part as well.

Otherwise your patch LGTM.

Best, Arash

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Paul D. Nelson" <ultrono <at> gmail.com>
Cc: 77381 <at> debbugs.gnu.org
Subject: Re: bug#77381: [PATCH] extend tex--prettify-symbols-alist
Date: Tue, 01 Apr 2025 14:32:56 +0300

> From: "Paul D. Nelson" <ultrono <at> gmail.com>
> Cc: 77381 <at> debbugs.gnu.org
> Date: Mon, 31 Mar 2025 22:33:59 +0200
> 
> One thing I realized is that the implementation I had given of the new
> function was incorrect in its handling of the frame argument, because
> the function char-displayable-p does seem to depend upon the selected
> frame (e.g., on a graphical terminal with multiple frames, each having
> their own default face or font-backend).

You are right, char-displayable-p is a mess in this regard.

> Assuming I haven't misunderstood, I saw a few options for correcting the
> new function:
> 
> 1. Wrap char-displayable-p in (with-selected-frame ...).
> 
> 2. Give char-displayable-p a frame argument, and wrap its body in
>    (with-selected-frame ...).
> 
> 3. Drop the frame argument altogether (leaving (with-selected-frame
>    ...) to callers of these functions).

I prefer (1), since we cannot change char-displayable-p itself (it's
used in too many places, including during startup).

> Option (3) seemed simplest to me, and also at the least risk of
> introducing confusion concerning the name of the new function: at a
> glance, "char-displayable-on-frame-p" might suggest incorrectly that it
> does the analogue for the given frame of what char-displayable-p does
> for the selected frame.

I acknowledge the potential confusion, but I think we can countermand
that in the doc string (without even mentioning char-displayable-p).

Thanks.

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

From: "Paul D. Nelson" <ultrono <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77381 <at> debbugs.gnu.org
Subject: Re: bug#77381: [PATCH] extend tex--prettify-symbols-alist
Date: Tue, 01 Apr 2025 13:59:17 +0200

[Message part 1 (text/plain, inline)]

>> 1. Wrap char-displayable-p in (with-selected-frame ...).
>> 
>> 2. Give char-displayable-p a frame argument, and wrap its body in
>>    (with-selected-frame ...).
>> 
>> 3. Drop the frame argument altogether (leaving (with-selected-frame
>>    ...) to callers of these functions).
>
> I prefer (1), since we cannot change char-displayable-p itself (it's
> used in too many places, including during startup).
>
>> Option (3) seemed simplest to me, and also at the least risk of
>> introducing confusion concerning the name of the new function: at a
>> glance, "char-displayable-on-frame-p" might suggest incorrectly that it
>> does the analogue for the given frame of what char-displayable-p does
>> for the selected frame.
>
> I acknowledge the potential confusion, but I think we can countermand
> that in the doc string (without even mentioning char-displayable-p).

Thanks, I've revised to (1).  Please see attached.

[0001-Restrict-symbol-prettification-to-displayable-ones.patch (text/x-patch, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Paul D. Nelson" <ultrono <at> gmail.com>
Cc: 77381 <at> debbugs.gnu.org
Subject: Re: bug#77381: [PATCH] extend tex--prettify-symbols-alist
Date: Sat, 05 Apr 2025 12:27:27 +0300

> From: "Paul D. Nelson" <ultrono <at> gmail.com>
> Cc: 77381 <at> debbugs.gnu.org
> Date: Tue, 01 Apr 2025 13:59:17 +0200
> 
> >> 1. Wrap char-displayable-p in (with-selected-frame ...).
> >> 
> >> 2. Give char-displayable-p a frame argument, and wrap its body in
> >>    (with-selected-frame ...).
> >> 
> >> 3. Drop the frame argument altogether (leaving (with-selected-frame
> >>    ...) to callers of these functions).
> >
> > I prefer (1), since we cannot change char-displayable-p itself (it's
> > used in too many places, including during startup).
> >
> >> Option (3) seemed simplest to me, and also at the least risk of
> >> introducing confusion concerning the name of the new function: at a
> >> glance, "char-displayable-on-frame-p" might suggest incorrectly that it
> >> does the analogue for the given frame of what char-displayable-p does
> >> for the selected frame.
> >
> > I acknowledge the potential confusion, but I think we can countermand
> > that in the doc string (without even mentioning char-displayable-p).
> 
> Thanks, I've revised to (1).  Please see attached.

Thanks, installed on the master branch.

Can this bug be closed now, or do we have anything else to do here?

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

From: "Paul D. Nelson" <ultrono <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77381 <at> debbugs.gnu.org
Subject: Re: bug#77381: [PATCH] extend tex--prettify-symbols-alist
Date: Sat, 05 Apr 2025 13:07:08 +0200

Thanks, resolved on my end.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Paul D. Nelson" <ultrono <at> gmail.com>
Cc: 77381-done <at> debbugs.gnu.org
Subject: Re: bug#77381: [PATCH] extend tex--prettify-symbols-alist
Date: Sat, 05 Apr 2025 15:19:22 +0300

> From: "Paul D. Nelson" <ultrono <at> gmail.com>
> Cc: 77381 <at> debbugs.gnu.org
> Date: Sat, 05 Apr 2025 13:07:08 +0200
> 
> Thanks, resolved on my end.

Closing.

Previous Next

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