[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#18: Fine-grained revert-buffer
From: |
Eli Zaretskii |
Subject: |
bug#18: Fine-grained revert-buffer |
Date: |
Sat, 27 Apr 2019 19:30:48 +0300 |
> From: Mauro Aranda <maurooaranda@gmail.com>
> Date: Sat, 27 Apr 2019 12:10:45 -0300
> Cc: Eli Zaretskii <eliz@gnu.org>, martin rudalics <rudalics@gmx.at>
>
> I didn't know of replace-buffer-contents, so I took a look at it. Nice
> that its documentation even mentions the problem when a marker is
> inside a hunk, because of the delete + insert thing (just like Martin
> mentions). IMO, it does most of the things required, but here is one
> problem I notice with respect to the expected functionality of
> revert-buffer-by-hunks (as I've understood it):
>
> It only calls Fundo_boundary before starting the whole set of
> modifications, and thus after replacing the contents (in my tests, the
> whole buffer), a single C-/ brings all the changes back, much like
> revert-buffer.
Is there a requirement to be able to undo the revert piecemeal? What
would be the use case for that?
> > Did you time your code? How long does it take to revert buffers of
> > different sizes with different amounts of changes?
>
> I haven't timed it yet. I didn't know if it would be considered good
> enough, to time it. For a week, I've been testing it manually with some
> of the changes in the Emacs sources, and the experience has been
> satisfactory. Are there, by any chance, such tests for
> replace-buffer-contents?
You can find one in bug#31888.
Also, this discussion:
http://lists.gnu.org/archive/html/help-gnu-emacs/2019-02/msg00000.html
indicates that using JSON pretty-printer might produce a good test
case.