Re: [Emacs-diffs] master 58a3c54: Avoid using string-make-unibyte in select.el

[Stefan Monnier]

> (a) I wouldn't call anything related to string-to-unibyte "clear",
> because the act of converting a string to unibyte is not well defined.
> (b) Encoding text can also be defined as "converting between two
> representations of a sequence of bytes".

No, encoding and decoding change the bytes, whereas string-to preserves
the bytes (just once represented as a unibyte string (which can never
be anything else than a sequence of bytes) and the other as a sequence
of chars (some of which stand for bytes)).

A sequence of bytes can be represented in many different ways:
- a unibyte string is the canonical way (because it can only do that,
  so when you receive such a thing you don't need to look for possible
  non-bytes in the sequence or for a non-proper sequence).
- a vector of integers between 0 and 255.
- a list of integers between 0 and 255.
- a multibyte string with chars within the union of the ascii charset
  and the eight-bit charset.
string-to lets you convert a given sequence of bytes between the first
and the last.

>> It's also code that clearly does the reverse of string-to-multibyte
>> (whereas decode-doding-string doesn't do the reverse of
>> encode-coding-string when it comes to `raw-text`).
> I think decode-doding-string does do the reverse.

No: decode-coding-string returns a unibyte string when called with
`raw-text` or `binary`, contrary to string-to-multibyte.

>> >> IOW coding-systems like `raw-text` make sense in places like the
>> >> `coding:` tag or in buffer-file-coding-system, where we are forced to
>> >> put some kind of coding-system and where it is hence handy to be able to
>> >> use `raw-text-unix` to basically skip the en/decoding.
>> >> But I find them confusing when passed as a constant to
>> >> `en/decode-coding-string`.
>> > It's the other way around here.
>> I don't know what "other way around" means in this context.
> It means that our preferences in this case are opposite.

AFAIK using `raw-text` or `no-conversion` in auto-coding-alist or in
`coding:` tags is not a matter of preference: you simply can't specify
string-to-*byte in there.


        Stefan