From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail
From: Eli Zaretskii <eliz@gnu.org>
Newsgroups: gmane.emacs.devel
Subject: Re: emacs-26 8f18d12: Improve documentation of decoding into
	a	unibyte buffer
Date: Tue, 28 May 2019 18:11:44 +0300
Message-ID: <83y32qzk9b.fsf@gnu.org>
References: <20190525191039.14136.23307@vcs0.savannah.gnu.org>
	<20190525191040.CCD6C207F5@vcs0.savannah.gnu.org>
	<m2blzo6xfs.fsf@gmail.com> <jwvr28kozn3.fsf-monnier+emacs@gnu.org>
	<m2k1ec9hjh.fsf@gmail.com> <jwva7f8owp7.fsf-monnier+emacs@gnu.org>
	<83v9xv2649.fsf@gnu.org> <jwvblznwvzi.fsf-monnier+emacs@gnu.org>
	<83imtv1fbf.fsf@gnu.org> <jwv5zpvwark.fsf-monnier+emacs@gnu.org>
	<7F0B61E6-C0CA-449B-B432-095569589168@gnu.org>
	<jwvy32qokvp.fsf-monnier+emacs@gnu.org>
Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226";
	logging-data="59925"; mail-complaints-to="usenet@blaine.gmane.org"
Cc: emacs-devel@gnu.org
To: Stefan Monnier <monnier@iro.umontreal.ca>
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 28 17:14:58 2019
Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>
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 <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	id 1hVdoW-000FOp-42
	for ged-emacs-devel@m.gmane.org; Tue, 28 May 2019 17:14:56 +0200
Original-Received: from localhost ([127.0.0.1]:36558 helo=lists.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	id 1hVdoU-0004Qc-HT
	for ged-emacs-devel@m.gmane.org; Tue, 28 May 2019 11:14:54 -0400
Original-Received: from eggs.gnu.org ([209.51.188.92]:59067)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <eliz@gnu.org>) id 1hVdlM-0002fG-Ow
	for emacs-devel@gnu.org; Tue, 28 May 2019 11:11:41 -0400
Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:60888)
	by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@gnu.org>)
	id 1hVdlM-0000Ly-FS; Tue, 28 May 2019 11:11:40 -0400
Original-Received: from [176.228.60.248] (port=3415 helo=home-c4e4a596f7)
	by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.82) (envelope-from <eliz@gnu.org>)
	id 1hVdlK-0003YP-0a; Tue, 28 May 2019 11:11:39 -0400
In-reply-to: <jwvy32qokvp.fsf-monnier+emacs@gnu.org> (message from Stefan
	Monnier on Tue, 28 May 2019 07:54:41 -0400)
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." <emacs-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-devel/>
List-Post: <mailto:emacs-devel@gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=subscribe>
Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org
Original-Sender: "Emacs-devel" <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>
Xref: news.gmane.org gmane.emacs.devel:237108
Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/237108>

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Tue, 28 May 2019 07:54:41 -0400
> 
> > string-to-unibyte is also marked obsolete.
> 
> Not any more:
> 
>     ;; We used to declare string-to-unibyte obsolete, but it is a valid
>     ;; (make-obsolete 'string-to-unibyte   "use `encode-coding-string'." "26.1")

OK, but how does this affect the issue at hand?  We want to replace
string-as-unibyte, or remove it, and the obsolescence message says to
replace it with encode-coding-string.  So if we cannot remove it for
some reason, it makes more sense to use encode-coding-string.  Either
way, using string-to-unibyte instead sounds less desirable to me.