[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: Sun, 23 Jun 2019 17:26:30 +0300

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

reply via email to

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