Subject: bug#58168: string-lessp glitches and inconsistencies

From: Eli Zaretskii <[email-masked]>
Date: Thu, 06 Oct 2022 14:13:43 +0300

> From: Mattias Engdegård <[email-masked]>
> Date: Thu, 6 Oct 2022 11:05:51 +0200
> Cc: [email-masked],
>  [email-masked]
> 
> 4 okt. 2022 kl. 18.24 skrev Eli Zaretskii <[email-masked]>:
> 
> >> This treats unibyte format strings as if they were Latin-1 for the purpose of the error message.
> > 
> > No, it doesn't.  It shows the problematic characters as raw bytes, as
> > in "%\200" (where \200 is a single character).  If you see something
> > different, please show the recipe.
> 
>    (format-message "%\345" 0)
> => (error "Invalid format operation %å")

And you want to show %\345 instead?  Are you sure this is not the
consequence of inserting the error message into a multibyte buffer?

> > Who said anything about #x3fffc?  The original code had #xfc, the
> > unibyte code for #x3ffffc.
> 
> There seems to be a misunderstanding. The original (and current) code attempts to display char #x3fffc, which is not a raw byte. It's just a typo for #x3ffffc -- not a big deal.

But your change replaced it with \xfc, which is what I questioned.
Why not test both #x3ffffc and #xfc?  And the same question about
\777777 vs \374.