all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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: Sat, 22 Jun 2019 12:44:05 -0400	[thread overview]
Message-ID: <jwvef3lwpuq.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <838sttohx8.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 22 Jun 2019 16:42:27 +0300")

>> > +            (or (null (multibyte-string-p str))
>> > +                (setq str (encode-coding-string 'raw-text-unix str))))
>> Isn't this the same as (setq str (string-to-unibyte str))?
> No, because the former doesn't signal an error.

Oh, right, that's yet another subtle distinction between all those alternatives.

BTW, do we actually need to convert to unibyte here?
(most place where we expect a unibyte string, we silently convert from
multibyte when needed, in a way that's basically equivalent to the
above).

> (And I didn't want to use any of those string-to/as-uni/multibyte
> functions anyway.)

I hated those functions and still do for the string-as and string-make
variety, but I'm beginning to like the string-to variety when we need to
convert the representation of a sequence of *bytes* within
encoding/decoding them as chars.

So maybe the present case argues for adding a `no-error` argument to
string-to-unibyte.  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".

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

> The only thing we are supposed to do in the multibyte case is to make
> sure the raw bytes are converted to their single-byte representation,
> which is exactly what raw-text-unix does.

Right (and indeed string-make-unibyte worked in practice for the same
reason that encoding with pretty much any coding-system preserves the
bytes as well, save for a few exceptions like utf-8-emacs).


        Stefan




  reply	other threads:[~2019-06-22 16:44 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 [this message]
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

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