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 13:48:27 -0400 Message-ID: References: <83d0ird3ka.fsf@gnu.org> <83muhvavsf.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="232051"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 03 19:52:49 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 1hijR3-000xzb-Ju for ged-emacs-devel@m.gmane.org; Wed, 03 Jul 2019 19:52:49 +0200 Original-Received: from localhost ([::1]:38120 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hijNx-0006dp-5z for ged-emacs-devel@m.gmane.org; Wed, 03 Jul 2019 13:49:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52773) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hijNE-0006c5-3S for emacs-devel@gnu.org; Wed, 03 Jul 2019 13:48:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hijN8-00007d-5J for emacs-devel@gnu.org; Wed, 03 Jul 2019 13:48:48 -0400 Original-Received: from 195-159-176-226.customer.powertech.no ([195.159.176.226]:53274 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hijN6-0008QO-4v for emacs-devel@gnu.org; Wed, 03 Jul 2019 13:48:46 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hijMw-000tBg-SG for emacs-devel@gnu.org; Wed, 03 Jul 2019 19:48:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:k76hS1K0sXAOlT3AuuvvcyPjjyM= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 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:238336 Archived-At: >> 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). > > I think we should do 2. I think as a user, after an error, I'd rather see the text decoded with `raw-text-unix` (which is what we get now) than no text at all. Also until now, the behavior has been to show the text we loaded, so this would be a more significant change. What would be the benefit of making the buffer empty? >> 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. > > I think we should restore undo-list, because (a) it isn't hard, and > (b) someone at some point will complain if we don't. Fair enough, I'll do that. >> > . 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). > I don't think I understand this. Are you saying that empty buffers > cannot have markers and overlays? No I'm saying that all the markers were at BOB and it's perfectly correct to have them moved elsewhere after the insertion of text in the buffer. The resetting of markers in the normal codepath is required for correctness reasons (without it, we can end up with markers pointing outside of the actual buffer text, for example), but in the non-local exit case it's not needed and would only throw away information. But if you prefer, I can move that back to the unwind function (along with the undo-list resetting), of course. Stefan