Subject: Re: bug#79311: 31.0.50; Some characters not displayed when using standard-display-table

From: Andy Moreton <[email-masked]>
Date: Tue, 26 Aug 2025 21:29:04 +0100

On Tue 26 Aug 2025, Eli Zaretskii wrote:

>> From: Andy Moreton <[email-masked]>
>> Date: Tue, 26 Aug 2025 08:57:36 +0100
>> 
>> On Tue 26 Aug 2025, Eli Zaretskii wrote:
>> 
>> >> From: Andy Moreton <[email-masked]>
>> >> Date: Mon, 25 Aug 2025 22:15:54 +0100
>> >> 
>> >> On Mon 25 Aug 2025, Eli Zaretskii wrote:
>> >> 
>> >> >> From: Matija Obid <[email-masked]>
>> >> >> Date: Mon, 25 Aug 2025 16:07:46 +0000
>> >> >> 
>> >> >> Steps to reproduce:
>> >> >> $ emacs -Q
>> >> >> #+begin_src elisp
>> >> >> (setq standard-display-table (make-display-table))
>> >> >> (aset standard-display-table ?> [?\〉])
>> >> >> (switch-to-buffer ">")
>> >> >> #+end_src
>> >> >
>> >> >> 
>> >> >> The buffer name in modeline is displayed as a square instead of parenthesis.
>> >> >
>> >> > Thanks, should be fixed now.
>> >> 
>> >> This seems to cause display glitches in gnus on Windows, when using
>> >> non-ASCII chars for the indicators in gnus-sum-thread-tree-* variables.
>> >> These glitches did no occur in a build from two days ago.
>> >> 
>> >> The symptom is the gnus summary buffer displays \xe2 characters, instead
>> >> of the expected character, e.g. WHITE SQUARE (codepoint #x25a1) which
>> >> has buffer code #xE2 #x96 #xA1.
>> >> 
>> >> The wrong display is transient, in that moving the cursor over the wrong
>> >> display fixes the glitch.
>> >
>> > Thanks, but please show a recipe starting from "emacs -Q", so I could
>> > look into this.
>> 
>> I can try, but it will take significant effort to produce such a
>> a restricted config.
>> 
>> After reverting only commit 21b072c60744 ("Fix use of display-table for
>> mode-line display") and rebuilding then the gnus summary buffer display
>> works as expected.
>
> I didn't doubt that the problem was with that change, I just didn't
> know how it could harm the Gnus summary buffer, which I never use,
> especially since your report seemed to indicate that you customized
> the indicators (the defaults are all ASCII characters).
>
> I hope the fix I installed for bug#79317 also fixes this problem.  If
> not, please describe what else is left to fix after that change.

Thanks Eli, the display appears to be as expected now.

    AndyM