From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 58a3c54: Avoid using string-make-unibyte in select.el Date: Sat, 22 Jun 2019 22:45:07 -0400 Message-ID: References: <20190622083524.20617.42423@vcs0.savannah.gnu.org> <20190622083525.F1CA5209DE@vcs0.savannah.gnu.org> <838sttohx8.fsf@gnu.org> <834l4ho8wv.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="158860"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 23 04:46:30 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hesWT-000fFD-QF for ged-emacs-devel@m.gmane.org; Sun, 23 Jun 2019 04:46:30 +0200 Original-Received: from localhost ([::1]:43062 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hesWS-0002nk-JN for ged-emacs-devel@m.gmane.org; Sat, 22 Jun 2019 22:46:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43551) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hesVO-0002kW-Iv for emacs-devel@gnu.org; Sat, 22 Jun 2019 22:45:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hesVN-0005Og-Ga for emacs-devel@gnu.org; Sat, 22 Jun 2019 22:45:22 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:23083) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hesVK-0005Ko-R5; Sat, 22 Jun 2019 22:45:19 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B162F443FFE; Sat, 22 Jun 2019 22:45:16 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 85F0F443FC3; Sat, 22 Jun 2019 22:45:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1561257915; bh=qtGFzssJrSCoe+91iFTzgXS3j7fDQnvu40iPYdMkXrE=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=FSmfoyDt/x0yYIZqPTGBtzxlNms9V7KZtB/qSvZXJcMIu/TJ0XqK+/VvucbWAQEL/ snIidLxaGueDh4wt0YzxlLl/Wy8f2++LkwtlCTV/miCKcw+6g/HBoAtKXEMQqar8Z7 7iBl/YQJ4xJ3mdlaKrLEYXX6f9Z2NOOKSkWs4/uC7CtdtaC64ARUZ7iDPBqdOiDisz 46FWvfpN3GKaWcTfDi+M92vTUFNhFLfQYQWriGnaNOiT8PTDo2xvhc2rB/E/vvxzxx oRp+qYXk8IpwcLmpeQlPVPXvr5ucWLFNwVZpNTWwYGQAwuNT/khdx+EqyavkE9o0Bu gYMkZvlNAx4YQ== Original-Received: from alfajor (104-195-207-100.cpe.teksavvy.com [104.195.207.100]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4FFED1206EB; Sat, 22 Jun 2019 22:45:15 -0400 (EDT) In-Reply-To: <834l4ho8wv.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 22 Jun 2019 19:57:04 +0300") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 132.204.25.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:238051 Archived-At: >> 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. 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 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. I also hate `no-conversion`. But for the same reason I dislike `raw-text` because the name gives me no intuition and since it is about preserving bytes rather than characters, it doesn't have much to do with "text". > That's why I didn't use 'binary' in this case. Binary doesn't say what the conversion does, indeed, but it does say that it applies to binary (rather than text) contents, so I find its name does provide the needed intuition. >> 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. Stefan