bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#27122: 26.0.50; [PATCH] Add customizable to display unprintables as


From: Eli Zaretskii
Subject: bug#27122: 26.0.50; [PATCH] Add customizable to display unprintables as hex
Date: Mon, 29 May 2017 22:39:54 +0300

> Date: Mon, 29 May 2017 08:28:59 +0200
> From: Vasilij Schneidermann <v.schneidermann@gmail.com>
> Cc: 27122@debbugs.gnu.org
> 
> OK, I'll go into a bit more detail on my envisioned use case.  Suppose
> you open a buffer just to discover that some of the bytes aren't decoded
> properly.  The culprits are \344, \366 and \374.  You suspect it's
> latin-1, so you open a Wikipedia page on it and find a table of its
> character mapping, however it's using hexadecimal instead of octal
> formatting.  Generally it seems that the world has moved on and prefers
> hexadecimal over octal formatting, except for `chmod` and Emacs.  You
> sigh and convert the octal to hexadecimal.  Your hunch about this being
> a latin-1 issue turns out to be true.  Why can't Emacs make this easier?

Does "C-x =" or "C-u C-x =" fit the bill in this case?  If the former
doesn't, how about adding the hex byte translation to what it shows?
IOW, what if instead of

  Char: \344 (4194276, #o17777744, #x3fffe4, raw-byte) point=...

"C-x =" would display this:

  Char: \344, #xe4 (4194276, #o17777744, #x3fffe4, raw-byte) point=...

> > We already have quite a few related features, and I wonder whether
> > you could simply use one of them.
> 
> The only one I'm aware of you could use instead is to manipulate the
> display table.

We also have the glyphless-char-display-control (and the underlying
char-table), although it will not help in your case.  Which is why I
asked for more details.

Also, some characters, hard-coded in the display engine, are handled
specially.  E.g., try "C-x 8 RET a0 RET" or "C-x 8 RET 2011 RET".





reply via email to

[Prev in Thread] Current Thread [Next in Thread]