[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#33205: 26.1; unibyte/multibyte missing in rx.el
From: |
Mattias Engdegård |
Subject: |
bug#33205: 26.1; unibyte/multibyte missing in rx.el |
Date: |
Wed, 7 Nov 2018 21:19:07 +0100 |
7 nov. 2018 kl. 20.10 skrev Eli Zaretskii <eliz@gnu.org>:
>> Perhaps those char classes didn't see much use.
>
> Definitely not. I cannot even think of a practical use case for them
> nowadays.
But were they useful back then, when they were added? If so, for what? Maybe
it's been lost in the mists of time.
>
>> 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.
If we are content with [:unibyte:]/[:multibyte:] = [:ascii:]/[:nonascii:], then
it would be nice if the code were obvious about it. Right now, ISUNIBYTE and
IS_REAL_ASCII differ, and it takes some digging to realise that they have the
same effect. Removing RECC_UNIBYTE/RECC_MULTIBYTE entirely and use
RECC_ASCII/RECC_NONASCII throughout would make the semantics clear.