RE: [VETO] Revert buffer patch
>>>>> "Andy" == Andy Piper
<andy(a)xemacs.org> writes:
Andy> I still think we are actually missing a function, something
Andy> like `refresh-buffer', since revert-buffer is too
Andy> fierce.
How about `sync-buffer' for the name? "Refresh" implies display
properties to me, ie, redoing all the expensive operations (fontlock,
semantic parsing) for the whole buffer. Exactly what you don't want.
For implementation, try something rsync-like and only revert those
regions of the buffer with actual changes. Since AFAIK font-lock is
line-oriented, a diff with a temporary file (buffer image) and a merge
in Lisp should be satisfactory. Since the diff is used immediately,
no context is needed, this should be only a few lines of Lisp to parse
and execute a non-context-diff patch. It would probably make sense to
look at font-lock with a view to optimizing line-oriented changes.
But now you've got several file i/o operations to worry about. And
this function might be called on non-text buffers, where diff may do
crazy things. Getting this right would be tricky.
I still think you are all looking at this from the wrong angle. I am *only*
trying to hit a sweetspot for version-controlled buffers where the only
thing that has changed is the modtime. Version-control implies source-code
so I suspect all the arguments about hooks and coding-systems and composed
buffers are moot because you would never want or care this optimization for
those buffers.
So lets try another approach. The problem with the current hooks is that
they do not interrupt the flow of control they just allow you to add extra
control. So why not introduce an extra hook, something like
revert-buffer-optimize-revert-hook that returns t if it succeeds and nil
otherwise. If it returns t then revert-buffer skips to the post-processing.
Then we could install an optimization on a per-mode basis (e.g. cc-mode) and
most everyone would be happy.
andy