Re: [VETO] Revert buffer patch
Andy Piper wrote:
And your suggestion is? The comparison is done against insert-file-contents
which will have already applied those auto-detected things. So right now I
believe that it should be safe in these environments.
not true. the user may have manually selected a different coding system last
time the file was read in. currently there's no way to retrieve this --
although i added a way to get at this to my mule ws, to make revert-buffer work
properly in a mule setting.
but there's a basic problem. the revert-buffer hooks can do anything, including
making use of data external to the file, and that data might have changed. so
it's not safe to do what you're doing.
anyway, there's already some code in insert-file-contents to avoid the
re-font-locking, if that's your primary concern. it *is* safe to do it there.
it's probably turned off right now. again, i did some work to reenable it in my
mule ws. fsfmacs goes farther and essentially does your exact trick of loading
the file into a temporary buffer and comparing. i do a lesser approach because
[a] i was concerned about memory usage with large files, [b] it didn't seem to
be worth it just to avoid re-font-locking; just use lazy-lock instead. we
already have deferred fontification for inserts.
can you explain what exactly is the slowness you're trying to avoid?
andy
> -----Original Message-----
> From: xemacs-patches-admin(a)xemacs.org
> [mailto:xemacs-patches-adminï¼ xemacs.org]On Behalf Of Stephen J. Turnbull
> Sent: Sunday, November 04, 2001 9:36 PM
> To: Andy Piper
> Cc: XEmacs Patches
> Subject: [VETO] Revert buffer patch
>
>
> VETO
>
> At the very least, do not default it on. And add documentation that
> the implications are unclear in environments like Mule and
> file-coding which apply auto-detected transformations to the buffer.
>
> >>>>> "Andy" == Andy Piper <andy(a)xemacs.org> writes:
>
> 2001-11-02 Andy Piper <andy(a)xemacs.org>
> * files.el (revert-uses-md5-equality): New.
> * files.el (revert-buffer): optimize reversion of files that have
> only had their permissions and modtime changed.
>
> This patch is surely broken in a Mule environment and possibly with eg
> jka-compr. You need to be a lot more careful about how you match the
> state (coding systems, etc) of the tmp buffer to the user's buffer
> before you insert the file.
>
> The common failures are all "safe" (unnecessary reversions occur) but
> I can think of ways to make this fail harmfully by manipulating coding
> systems, and with the right file contents. I can't imagine a user
> doing those things, but it does suggest the possibility that there
> could be natural behavior that creates a buffer that needs reversion
> but doesn't get it. We shouldn't risk that.
>
> --
> Institute of Policy and Planning Sciences
> http://turnbull.sk.tsukuba.ac.jp
> University of Tsukuba Tennodai 1-1-1 Tsukuba
> 305-8573 JAPAN
> Don't ask how you can "do" free software business;
> ask what your business can "do for" free software.
>