emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] emacs-26 0feb673: Display raw bytes as belonging to 'e


From: Eli Zaretskii
Subject: Re: [Emacs-diffs] emacs-26 0feb673: Display raw bytes as belonging to 'eight-bit' charset
Date: Sat, 28 Jul 2018 18:15:28 +0300

> From: Stefan Monnier <address@hidden>
> Date: Sat, 28 Jul 2018 10:15:39 -0400
> 
> I know and understand what this charset is for.  Yet I don't see why
> eight-bit-control chars should be reported as belonging to this charset
> (any more than they should be reported to belong to any of the other
> charsets to which they may also belong, such as all the iso8859
> charsets).

Because ISO-8859 charsets don't include bytes between 128 and 159
(inclusive), I guess.

> I believe this happens only by accident: it seems to be the only charset
> of its kind defined with `:superset (... eight-bit-control ...)` and
> without :supplementary-p.

It's true it's the only such combination, but it is much less clear to
me why do you think this is an accident.  It could be, but I see no
reason to assume that without some independent evidence.  I asked
Handa-san to comment on that in the hope that he might be able to shed
some light on this situation (and on the use of :supplementary-p in
general).

> But maybe the real source of the problem is that eight-bit-control is
> defined as :supplementary-p (hard to tell, because I only see doc of
> how/when :supplementary-p should be used, but not what it does).

Maybe.  And again, I don't see why you'd assume it's a bug.

> > You are asking why we have this charset in the first place?
> 
> No, I understand why we have it, what I don't understand why it should
> be considered anything but a bug that eight-bit-control chars should be
> considered as belonging to that charset instead of to the
> eight-bit-control charset

We actually don't want to expose eight-bit-control to users at all, we
want there to be a single charset called 'eight-bit' covering all the
raw bytes.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]