bug#13177: 24.3.50; doc of `read-char-by-name'

[Drew Adams]

> > Great.  That's what I would prefer also.  And that was exactly what
> > I said in the original bug report: that's what the other `read*'
> > functions do: return the thing their names say they read.
> 
> `read-char' says it reads a character but it returns 0 (^@) for
> invalid characters.  I see no reason why 0 would be better than nil.
> Using an arbitrary character ^@ for invalid characters makes no sense.

OK, perhaps my analogy was too black & white.  Let's try to deal with
`read-char' exceptions to returning a char in a separate thread.  Keep in mind,
though, that `read-char' has been around even longer (a lot longer) than
`read-char-by-name', so changes would like affect more 3rd-party code.

Also, `read-char' returns non-char events, which is why we also have
`read-char-exclusive'.  Anyway, let's not let my analogy get in the way too
much; let's concentrate here on `read-char-by-name' and try to figure out what
the best behavior (and then doc) would be.

> > So we start with a code bug - make sure it always returns a char.
> > Then we fix the doc.  Anyway, FWIW you've got my vote in favor of
> > fixing the code to always return a char.
> 
> Also in bug#13195 the same request:
> 
> > Seems like `read-char-by-name' should always return something
> > that `insert-char' can use, i.e., something that passes 
> > `characterp'.
> 
> Yes, to always return a valid char or nil, we could check for 
> `characterp' like in the patch below.

Why return nil ever?  That's still part of the discussion, AFAIK.  nil is not a
character.