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

[Dmitry Gutov <dgutov@yandex.ru>]

On 30.11.2013 04:29, Stefan Monnier wrote:
> Note that a solution that applies only to ChangeLog wouldn't help for
> the `elpa' branch.  And hopefully at some point it won't help for
> `emacs' either because we'll have finally rid ourselves of the
> ChangeLog files.

Ok, good point. If other contributors have no new suggestions, I'll be 
content with a user option.

> We could easily highlight Summary specially after the Nth character.
> [ Not sure why it should be 50, and that number might need to
>    depend on the backend, but other than that, I don't see
>    any particular difficulty.  ]

50 is just a convention, so it shouldn't be inherently different for any 
other backend. And a safe-local user option will allow users to set it 
per project.

>> Actually, now that I've checked, `C-c C-k' in both `message-mode' and
>> git-commit-mode' that Magit uses kill the buffer after doing some cleanup,
>> not bury it. Would you be fine with that?
>
> 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'?

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

>> I think it can look better than using a separate window.  But then again,
>> it's how other editors do it, so it might just be more familiar.
>
> I used a separate window because it seemed easier, avoiding the usual
> problems with display-only-text or with text-that-will-disappear, which
> both can lead to surprising behaviors for the unsuspecting user.

Ok, I can work with either approach.