[Top][All Lists]

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

reply via email to

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