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

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden
> Date: Sat, 22 Jun 2019 22:45:07 -0400
> 
> >> 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.

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

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

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