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 fe3676f: (Finsert_file_contents): Keep buffer consistent in non-local exit Date: Wed, 03 Jul 2019 12:43:10 -0400 Message-ID: References: <83d0ird3ka.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="236354"; 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 Wed Jul 03 18:50:54 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 1hiiT4-000z5v-GB for ged-emacs-devel@m.gmane.org; Wed, 03 Jul 2019 18:50:50 +0200 Original-Received: from localhost ([::1]:37636 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hiiQ2-0003pw-ON for ged-emacs-devel@m.gmane.org; Wed, 03 Jul 2019 12:47:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39119) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hiiLt-00024x-NK for emacs-devel@gnu.org; Wed, 03 Jul 2019 12:43:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hiiLr-00043X-Mx for emacs-devel@gnu.org; Wed, 03 Jul 2019 12:43:25 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:30017) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hiiLl-0003uL-27; Wed, 03 Jul 2019 12:43:17 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id DD2BA4444CE; Wed, 3 Jul 2019 12:43:12 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 680ED4444B3; Wed, 3 Jul 2019 12:43:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1562172191; bh=j0zeOjnZBYARTrQp2Sg+t9FmbwnYJw36xk7aBrlcvtQ=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=owt/litFWkmf7UUkOtjtzK4L8PD7Nd35AI5watxTR2zZa5nLAPbfX0NjH2X9vzKbX nx9qceJtVdNT+SGjdl8yhG6hzWMu0DTH87mBgRP3oDt9p1iTPhXR6trO/0pvh1mMCP RQ/FdOJJpzMZFSn2bbBZgUlf8HNg6Gx8T9ERA6T6Z7iYKAeBIxQNh9D3sET0xl8F86 tc8Rt++Vp5FBgUjCP1tP0E0chTkXNW4DQyJoi3spysvUE8xt+3ECR+c0DW3m13jhrK aDVcLe/G6LLoZRGP6kxYUjiaL1U5XA+uOwxjiLeR4aoYY9ZF5lU/tImjF4NmSbcyE8 mNAyi+N5OtKbA== Original-Received: from pastel (76-10-141-139.dsl.teksavvy.com [76.10.141.139]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3E58E120A70; Wed, 3 Jul 2019 12:43:11 -0400 (EDT) In-Reply-To: <83d0ird3ka.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 03 Jul 2019 09:39:49 +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:238332 Archived-At: > Is it right to remove decode_coding_unwind? If set-auto-coding or > find-operation-coding-system signal an error, we will now: > > . leave the buffer unibyte and with undo-list bound to t Since the error happens before decoding and even before we have chosen a coding-system, there aren't many choices in this respect: 1- do as I do now (i.e. stay in unibyte even if the buffer was originally in multibyte). 2- erase the text we loaded (i.e. all the text, since the buffer started as empty) and revert the buffer to its original multibyteness state. 3- decode the text with some "default" coding system. Note that the behavior (1) basically corresponds to a `no-conversion` coding system (since such a coding system also forces the buffer to unibyte). 4- keep the old "arbitrary bytes in a multibyte buffer" bug. I think only (4) is clearly inferior and neither of the other is clearly superior, so I went with the easier choice, especially since it's expected to be a very rare corner case occurrence anyway (after all, we lived with (4) for many years). W.r.t the undo-list, I don't have a good reason for this choice, it was just easier. Since the buffer started as empty, there's a good chance that the undo list had no interesting info anyway, so I felt like this is even less important. > . fail to reset the markers and overlays to their previous state > . fail to reset intervals These only need to be "reset" in the normal code path because we remove the text from the buffer (to put it into the gap and then decode it), but since in this case we don't remove the text, there's no need to do that (and remember that the buffer was empty to start with so there's not much "previous state" to restore in this respect). Stefan