[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Emacs-diffs] master 58a3c54: Avoid using string-make-unibyte in sel
From: |
Eli Zaretskii |
Subject: |
Re: [Emacs-diffs] master 58a3c54: Avoid using string-make-unibyte in select.el |
Date: |
Sat, 22 Jun 2019 19:57:04 +0300 |
> From: Stefan Monnier <address@hidden>
> Cc: address@hidden
> Date: Sat, 22 Jun 2019 12:44:05 -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?
> 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. That's why I
didn't use 'binary' in this case.
> 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.