xemacs-patches removed from cc list. Andy> And your suggestion is? The comparison is done against Andy> insert-file-contents which will have already applied those Andy> auto-detected things. And what if the user intentionally _hasn't_? The point is that this works correctly in the most common case but it does absolutely _nothing_ to handle cases where the user knows better than the autodetect logic. OK, here's an automatic example that hits you where you live. Text file. Autodetect EOL. In the repository, somebody global-replaces LF with CRLF. Buffer needs reversion, your algorithm gets it wrong. The best thing I can think of is to save the buffer to a temporary file and compare that with the file on disk. Use insert-file-contents-literally if you're going to do in an in Emacs buffer. -- 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.

At 09:29 AM 11/6/2001 -0700, Ben Wing wrote: lazy-lock has always been a royal PITA for me. I would prefer a more general solution. Its a combination of things. When you revert a Java file you not only get the buffer re-font-locked but semantic does its parse and that information is used for extra font-locking and the whole process is *really* slow. Now when the *only* thing that has happened is that the modtime and permissions have changed on the file it seems *really* stupid. There really should be some way of detecting this. I think the more basic problem is that revert-buffer is the wrong API to be using in many cases but it is the only one that allows you to switch off user-prompting. (for instance find-file-noselect might be a better thing to use if it had the correct API). andy

At 05:02 PM 11/6/2001 -0500, Pete Ware wrote: That's kind of what I did. andy

At 05:36 PM 11/6/2001 -0500, Paul Krause wrote: Yeah, I get this. I think its actually a bug in XEmacs related to revert-buffer. Doing the md5 thing avoids both problems. andy

Andy Piper wrote: some suggestions in how to make this patch workable: 1] it's never ok to hide a bug by working around it rather than fixing it. 2] don't do anything clever like use md5. 3] keep in mind there are many revert-buffer hooks, some of which explicitly replace the normal operation of inserting the file. your patch as is completely runs over them. the only hook that you can [reasonably safely] optimize away is `after-revert-hook' [and possibly `before-revert-hook']. to make your patch safe, it would have to do all the steps to actually revert the buffer, but do it in another buffer, and then finally compare the results and skip calling `after-revert-hook' if they're the same. if semantic hooks off of `after-revert-hook' [which it probably does], you're in luck. with a bit of effort you can also avoid having the before/after-change functions called. 4] if you do implement this, it should *always* be on. no variable to control its behavior. instead, we simply make a behavior change in `after-revert-hook' -- it's not called if the buffer contents don't change as a result of the revert. for reference, here's the doc for revert-buffer: (revert-buffer &optional IGNORE-AUTO NOCONFIRM PRESERVE-MODES) Documentation: Replace the buffer text with the text of the visited file on disk. This undoes all changes since the file was visited or saved. With a prefix argument, offer to revert from latest auto-save file, if that is more recent than the visited file. This command also works for special buffers that contain text which doesn't come from a file, but reflects some other data base instead: for example, Dired buffers and buffer-list buffers. In these cases, it reconstructs the buffer contents from the appropriate data base. When called from Lisp, the first argument is IGNORE-AUTO; only offer to revert from the auto-save file when this is nil. Note that the sense of this argument is the reverse of the prefix argument, for the sake of backward compatibility. IGNORE-AUTO is optional, defaulting to nil. Optional second argument NOCONFIRM means don't ask for confirmation at all. Optional third argument PRESERVE-MODES non-nil means don't alter the files modes. Normally we reinitialize them using `normal-mode'. If the value of `revert-buffer-function' is non-nil, it is called to do all the work for this command. Otherwise, the hooks `before-revert-hook' and `after-revert-hook' are run at the beginning and the end, and if `revert-buffer-insert-file-contents-function' is non-nil, it is called instead of rereading visited file contents. ben

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

At 02:28 AM 11/16/2001 -0700, Ben Wing wrote: Lets back up a bit here, I am only trying to hit the sweet spot of reverting buffers with NO changes. andy

Your original proposal concerned optimizing away after-revert-hook, I still don't see how that jives with what I am trying to achieve. andy

Ben, Please add some more words to your explanation so that it makes sense to lesser mortals like me. Thanks andy

Thanks. I will work on this. andy

Andy Piper wrote: why do we need this? why don't we just implement the general method i laid out concerning how to optimize this? what "mode-specific" or whatever-else-specific optimizations do we need? you've never specified any objections to my proposal, yet you propose a different one that introduces yet another hook, for no obvious reason, and would force all modes to do something that [as far as i know] is not mode-specific and has a general solution, as i laid out.

Andy Piper wrote: just disable the change hooks while you're inserting into a temp buffer. once you do the compare, and the results are the same, leave the old buffer as is. no triggering of font-lock. there is also code in insert-file-contents to figure out how much has changed -- it searches for a region [hopefully small] containing all the changes, and then arranges for the extents and markers to be preserved in the remaining text [essentially by just deleting and replacing the changed section]. to work properly in the case of coding systems, etc. you need to insert into a temp buffer and do the compare. we don't actually implement this code currently, but fsf does (but DO NOT TRY to copy their implementation, you'll just cause more grief for yourself). the only reason to do all this [provided your more general revert code is in] is in the case where only a small change was made before reverting, and it only affects font-lock [and only if you don't use lazy-lock], so it may not be worth fussing with. NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!!! not another api doing exactly what an existing one does just fine, provided the correct optimizations are there. adding user-callable functions is tantamount to adding new options, and there needs to be a clear benefit that outweighs the confusion. just correctly implement the revert-buffer optimizations the way i've outlined them, and you'll get everything nice and speedy without any need for a kludgy vfork equivalent.

Paul> That's for sure. It especially bites me when I compile and skip to the Paul> next-error, which is usually line 2394 in a 3500 line file. The file gets Paul> fontified and parsed, but to edit it, but have to check out from perforce. Paul> Then not only does the fortification and parsing start all over, but the Paul> buffer-position gets trashed (probably an unrelated bug in perforce.el, but Paul> I never figured it out), and I'm back on line 1 again. Kinda sucks. I get the same problem with clearcase.el. Fortunately, my files aren't thousands of lines long. :-) This is quite annoying, but not so annoying that I've spent any real time trying to find out why. Ray