Re: trunk r115265: * lisp/vc/vc-dispatcher.el (vc-log-edit): Setup the Summary&Author headers.

[Stefan Monnier]

>> Seems a bit pointless since C-x k (and kill-this-buffer) works as well
>> for *VC-Log*, AFAIK.
> Why do we have `message-kill-buffer', `rcirc-multiline-minor-cancel' and
> org-kill-note-or-show-branches'?

Can't tell you without looking at them.  Presumably they do more than
just kill the buffer and using a kill-buffer-hook was not an option..
In the case of message-kill-buffer' it seems to be trying to deal with
the fact that the content of the buffer is like that of an unsaved file,
but buffer-file-name is non-nil, so it can't rely on the standard
kill-buffer handling.

In the case of *VC-Log* we could have a kill-buffer-hook which prompts
the user and aborts the kill if the user says he doesn't want to throw
away his incomplete comment.  But as you point out below, we could also
instead have a kill-buffer-hook which saves the incomplete comment to
log-edit-comment-ring so the buffer can be deleted without losing
valuable info and hence without prompting.

> As I see it, they mean "abort the current action, clean up its data, restore
> the previous window configuration". Having a similar command with the same
> binding in log-edit would be natural. Among other things, it would delete
> the *log-edit-files* window and quit-window on the current buffer (maybe
> deleting the window as a result).

We might indeed provide a key to "hide" the *VC-Log* buffer without
killing it.  And that should hide (or kill) the *log-edit-files* as well.

> We can go against the similar commands and refrain from killing the buffer,
> but why keep it? We can also save the aborted commit message to
> log-edit-comment-ring.

As long as the data is stored in log-edit-comment-ring I think it's OK
to kill without prompting.


        Stefan