Re: Displaying bytes (was: Inadequate documentation of silly characters on screen.)

[Richard Stallman <rms@gnu.org>]

    > Basically, it isn't clear that \361 is a byte rather than a character,
    > and what difference that ought to make, and what you should do
    > if you want to turn it from a byte into a character.

    So how do you suggest we represent the byte 241?

No better way jumps into my mind.  But maybe we could figure out some
way to make the current way easier to understand.

For instance, C-u C-x = on \224 says

	    character: ” (4194196, #o17777624, #x3fff94)
    preferred charset: tis620-2533 (TIS620.2533)
	   code point: 0x94
	       syntax: w 	which means: word
	  buffer code: #x94
	    file code: #x94 (encoded by coding system no-conversion)
	      display: not encodable for terminal

    Character code properties: customize what to show

    [back]

Perhaps it should say, 

	    character: Stray byte ” (4194196, #o17777624, #x3fff94)

What are the situations where a user is likely to see these stray
bytes.  When visiting a binary file, of course; but in that situation,
nobody will be surprised or disappointed.  So what are the other
cases, and what might the user really want instead?  Does it mean the
user probably wants to do M-x decode-coding-region?  If so, can we find a way
to give the user that hint?

When I click on tis620-2533 in that output, I get this

    Character set: tis620-2533

    TIS620.2533

    Number of contained characters: 256
    ASCII compatible.
    Code space: [0 255]

    [back]

which is totally unhelpful.  What is this character set's main
purpose?  Does it exist specifically for stray non-ASCII bytes?
If so, saying so here would help.  If not -- if it has some other
purpose -- then it would be good to explain both purposes here.

Also, if it exists for these stray non-ASCII bytes, why does it have
256 chars in it?  There are only 128 possible stray non-ASCII bytes.

(It is also not clear to me what "ASCII compatible" means in this
context.)