unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
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	[thread overview]
Message-ID: <jwvsgrngjx8.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <83d0ird3ka.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 03 Jul 2019 09:39:49 +0300")

> 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




  reply	other threads:[~2019-07-03 16:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-03  6:39 [Emacs-diffs] master fe3676f: (Finsert_file_contents): Keep buffer consistent in non-local exit Eli Zaretskii
2019-07-03 16:43 ` Stefan Monnier [this message]
2019-07-03 17:10   ` Eli Zaretskii
2019-07-03 17:48     ` Stefan Monnier
2019-07-04 13:28       ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvsgrngjx8.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).