bug#17758: 24.3; The line isn't wrapped during printing if it contains non ascii chars

[Lars Ingebrigtsen]

Mattias Engdegård <mattiase@acm.org> writes:

> Yes, this is by design. The former is the range U+0000..U+00FF and
> covers Latin-1. The latter covers ASCII and raw bytes, but no
> non-ASCII Unicode characters.
>
> It is what we get when one interval endpoint is ASCII and the other a
> raw byte; it is mainly intended for regexp matching in unibyte
> text. Since the Emacs multibyte encoding puts the raw bytes 80..FF at
> the very end of the character numbering, [\000-\377] would include
> every Unicode character (which would be very surprising) if we didn't
> have this mechanism.

It makes sense, but when playing with this, I looked at the "range" item
in the "Regexp Special" node in the elisp manual, and it doesn't look
like this quirk is documented?  (But it's a long node, perhaps I missed
something when skimming it.)

And this bit seems to actively discourage the change I did here:

--
Although a range's bound can be almost any character, it is better
style to stay within natural sequences of ASCII letters and digits
because most people have not memorized character code tables.
For example, @samp{[.-9]} is less clear than @samp{[./0-9]},
and @samp{[`-~]} is less clear than @samp{[`a-z@{|@}~]}.
Unicode character escapes can help here; for example, for most programmers
@samp{[ก-ฺ฿-๛]} is less clear than @samp{[\u0E01-\u0E3A\u0E3F-\u0E5B]}.
--

So I think a couple of lines mentioning raw bytes vs. Latin-1 would he
helpful here.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no