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

[Stefan Monnier]

>> So maybe the present case argues for adding a `no-error` argument to
>> string-to-unibyte.
> What is the use case for string-to-unibyte that cannot be satisfied by
> encoding with raw-text/binary, if we also don't signal an error?

The use case is clear code that says explicitly that this chunk of code
is not trying to convert between chars and bytes but only to convert
between two representations of a sequence of bytes.

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 say this because to me (encode-coding-string 'raw-text-unix str)
>> is an oxymoron since `raw-text-unix` is a synonym of `binary` and
>> `no-conversion`, which basically says "do any encoding/decoding,
>> instead preserve bytes as bytes".
>
> For reasons of avoiding mental overload, I prefer not to use
> no-conversion where in fact there is a conversion.

I also hate `no-conversion`.  But for the same reason I dislike
`raw-text` because the name gives me no intuition and since it is
about preserving bytes rather than characters, it doesn't have much to
do with "text".

> That's why I didn't use 'binary' in this case.

Binary doesn't say what the conversion does, indeed, but it does say
that it applies to binary (rather than text) contents, so I find its
name does provide the needed intuition.

>> 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.


        Stefan