[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Emacs-diffs] master fe3676f: (Finsert_file_contents): Keep buffer c
Re: [Emacs-diffs] master fe3676f: (Finsert_file_contents): Keep buffer consistent in non-local exit
Thu, 04 Jul 2019 16:28:16 +0300
> From: Stefan Monnier <address@hidden>
> Date: Wed, 03 Jul 2019 13:48:27 -0400
> > 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?
I think our usual practice is to roll back any failed operations,
leaving things as they were before the problematic transaction
> > 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.
To reset the undo-list, you already need an unwind function, right?
If you are sure that markers and overlays will not be affected by
insertion that was aborted half-way, then the unwind function doesn't
need to do anything with them. I couldn't convince myself that none
of these will be affected.