Re: [VETO] Revert buffer patch

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?