From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: [Emacs-diffs] master 58a3c54: Avoid using string-make-unibyte in select.el
Date: Sun, 23 Jun 2019 23:48:39 -0400 [thread overview]
Message-ID: <jwvwohbvehf.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <83v9wwml7t.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 23 Jun 2019 17:26:30 +0300")
> (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".
No, encoding and decoding change the bytes, whereas string-to preserves
the bytes (just once represented as a unibyte string (which can never
be anything else than a sequence of bytes) and the other as a sequence
of chars (some of which stand for bytes)).
A sequence of bytes can be represented in many different ways:
- a unibyte string is the canonical way (because it can only do that,
so when you receive such a thing you don't need to look for possible
non-bytes in the sequence or for a non-proper sequence).
- a vector of integers between 0 and 255.
- a list of integers between 0 and 255.
- a multibyte string with chars within the union of the ascii charset
and the eight-bit charset.
string-to lets you convert a given sequence of bytes between the first
and the last.
>> 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.
No: decode-coding-string returns a unibyte string when called with
`raw-text` or `binary`, contrary to string-to-multibyte.
>> >> 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.
AFAIK using `raw-text` or `no-conversion` in auto-coding-alist or in
`coding:` tags is not a matter of preference: you simply can't specify
string-to-*byte in there.
Stefan
prev parent reply other threads:[~2019-06-24 3:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190622083524.20617.42423@vcs0.savannah.gnu.org>
[not found] ` <20190622083525.F1CA5209DE@vcs0.savannah.gnu.org>
2019-06-22 8:58 ` master 58a3c54: Avoid using string-make-unibyte in select.el Lars Ingebrigtsen
2019-06-22 9:38 ` Eli Zaretskii
2019-06-22 13:26 ` [Emacs-diffs] " Stefan Monnier
2019-06-22 13:42 ` Eli Zaretskii
2019-06-22 16:44 ` Stefan Monnier
2019-06-22 16:57 ` Eli Zaretskii
2019-06-23 2:45 ` Stefan Monnier
2019-06-23 14:26 ` Eli Zaretskii
2019-06-24 3:48 ` Stefan Monnier [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvwohbvehf.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.