Re: [VETO] Revert buffer patch

> >>>>> "Andy" == Andy Piper <andy(a)xemacs.org&gt; 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