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.
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.