bug#33205: 26.1; unibyte/multibyte missing in rx.el

[Eli Zaretskii]

> From: Mattias Engdegård <mattiase@acm.org>
> Date: Wed, 7 Nov 2018 19:08:43 +0100
> Cc: 33205@debbugs.gnu.org
> 
> I'm not sure what I expected [\000-\377] to mean in a multibyte string; one 
> endpoint is ASCII and the other is a raw byte. It does work, as you noted, 
> because two ranges are generated, as if written [\000-\177\200-\377].

Octal escapes usually mean raw bytes.  Cf the fact that you used \310
in your original recipe.  So the above is expected to match raw bytes
and ASCII characters, i.e. what [:unibyte:] should probably stand for.

> In old Emacs versions (I tried 22.1.1), [:unibyte:] appears to include raw 
> bytes in multibyte strings/buffers, and everything in unibyte strings/buffers 
> (aka [\000-\377] in both cases), and [:multibyte:] the complement of that. 
> Thus, at some point the behaviour changed, but I cannot find any NEWS 
> reference to it. It could have been an accident.

Almost everything regarding internals of unibyte and multibyte
characters changed when we switched to UTF-8 superset as internal
representation.  One consequence is that raw bytes are no longer
represented as themselves in buffers and strings.

> Perhaps those char classes didn't see much use.

Definitely not.  I cannot even think of a practical use case for them
nowadays.

> The old behaviour seems a little more intuitive, but it must be rare to need 
> regex matching of rubbish bytes in multibyte strings. If you could argue that 
> the status quo is fine then I wouldn't necessarily object, but would suggest 
> that at least the code be made explicit about it (and the documentation, as 
> well).

I can fix the docs, but I don't think I understand what would you like
to do about the code.

> > Well, what do you think now?  Is it worth adding those to rx.el? I'm
> > not sure.  How important is it to find unibyte characters in a string,
> > anyway?
> 
> Unless we manage to make [:unibyte:]/[:multibyte:] more useful in their own 
> right, it's fine to leave rx.el as is, as far as I'm concerned. There is no 
> loss of expressivity.

OK.