From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Towards a cleaner build Date: Fri, 17 May 2019 11:16:39 +0300 Message-ID: <83tvdtbimw.fsf@gnu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="158421"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 17 10:16:56 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.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hRY2x-000f5s-Re for ged-emacs-devel@m.gmane.org; Fri, 17 May 2019 10:16:55 +0200 Original-Received: from localhost ([127.0.0.1]:44209 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hRY2w-0006X5-FF for ged-emacs-devel@m.gmane.org; Fri, 17 May 2019 04:16:54 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55439) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hRY2p-0006Wm-VL for emacs-devel@gnu.org; Fri, 17 May 2019 04:16:48 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38020) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hRY2p-0005qf-Qk; Fri, 17 May 2019 04:16:47 -0400 Original-Received: from [176.228.60.248] (port=3270 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hRY2p-0005oR-5c; Fri, 17 May 2019 04:16:47 -0400 In-reply-to: (message from Lars Ingebrigtsen on Fri, 17 May 2019 05:32:58 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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:236631 Archived-At: > From: Lars Ingebrigtsen > Date: Fri, 17 May 2019 05:32:58 +0200 > > In xselect--encode-string: > select.el:475:24:Warning: ‘string-make-unibyte’ is an obsolete function (as of > 26.1); use ‘encode-coding-string’. > > This is the code: > > ((eq type 'C_STRING) > (setq str (string-make-unibyte str))) > > (string-make-unibyte "á☪foo") > => "\341*foo" This example is not relevant, because C_STRING is for strings that are actually binary blobs, i.e. sequences of raw bytes. If you use examples of human-readable text, you get the wrong impression of what is intended. > I'm guessing the point here is to make an 8-bit string that is somewhat > congruent with the (possibly) multibyte string that we have here? The point here is to convert our internal multibyte representation of raw bytes into their external single-byte representation. > Do we have a library function (or a coding system) that does the > same thing? Yes, it's called string-make-unibyte ;-) I'm not sure we have anything else, but let me dwell on this for a while. Btw, your other change in select.el was incorrect, and I reverted it. For starters, when we need to _decode_ text (which is what gui-get-selection does, since it imports text into Emacs), it can never be TRT to _encode_ it. And second, there's no such coding-system as 'eight-bit', that's a name of a charset. (coding-system-p 'eight-bit) => nil So something like (encode-coding-string FOO 'eight-bit) will do nothing useful, and just signal an error. In general (with the possible exception of Gnus ;-), the places where we left those string-make/to/as-uni/multibyte thingies are there not because we were lazy, but because the replacements are either not trivial or don't exist. The deprecation message's advice in most of these cases is simply misleading. So I welcome work on these places, but my advice is to discuss each one of them before making changes, lest we break the code in some more or less subtle use cases. Thanks.