Hi Sean, thanks for your comments. > - Why ediff? Why not plain diff? The latter is lighter weight, and is > what diff-buffer-with-file uses, and your new command feels similar to > diff-buffer-with-file, to me. "ediff" because that's what I've typically used more, but I agree that it makes sense to have a "diff" analogue, so I've added one (attached). > - Have you thought about automatically detecting how far to go back, > somehow? We already have a feature whereby autosaves are disabled if > the buffer text has shrunk a lot; maybe that heuristic could help > here. Probably this would want to be a separate command so the manual > version was still available. > In practice, I've just spammed C-u enough times. I considered allowing a negative argument to signal "undo everything", which would be most useful with an active region; how does that sound? I hadn't thought about automatic detection along the lines that you suggest. I think I'm happy to leave that for now, either to a refinement of this command or a future one. >> + (orig-buf (current-buffer)) >> + (current-major major-mode) >> + (undo-buf-name (concat "UNDO=" (buffer-name orig-buf))) > > A more usual name would be " *ediff-undo*", I think. The space means > it is considered an internal buffer. (I know you're copying other ediff > practice with this FOO= thing but let's not introduce more.) I'm hesitant to mark it as internal since other Ediff functions don't automatically delete modified non-indirect buffers without user-defined cleanup hooks. In particular, I think it would be confusing if this function behaved differently from ediff-current-file, although I see your point about naming conventions. Perhaps "*ediff-undo*" would be more suitable? >> + (funcall current-major) > > Could you explain why the temporary buffer needs to be set to the major > mode? Is it for font lock/syntax highlighting, essentially? Another reason is that users might edit the "undo" buffer during the Ediff session, in which case standard keybindings are useful. Other suggestions would be welcome here. Paul