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

[Dmitry Gutov]

On 29.11.2013 19:04, Stefan Monnier wrote:
> I think of this "reminding" as a process rather than a one-time event,
> so I'm not too worried about it being "too late".
> It's not perfect, but it's better than nothing, I think.

If people not mentioning actual authors of contributed patches in 
ChangeLog is a real problem (I'm not sure it is), how about augmenting 
the ChangeLog font-locking instead, to highlight this field more 
prominently, prepend it with ephemeral text "Author:", and/or add help 
echo that would remind them that this field is for the actual author and 
their email.

> Having an extra empty "Author:" field might hurt your aesthetic
> sensibility, but I don't see how it could be really harmful, so I think
> it's perfectly OK even if it's hard to override (and of course, it can
> still be overridden, if you're sufficiently motivated).

Indeed, it's not the end of the world.

> > > The RFC822 format does add features, since there are a few other special
> > > headers (Author, Fixes, Amend, maybe a few more).
> > True.  But is it relevant to the question of whether to include the Summary
> > and Author headers by default?
>
> What would you include, instead?

I don't know. "Fixes:"? :)

Why do we need to include anything at all? If this desire has anything 
to do with the black line that can show up even when there are no actual 
headers above it, I believe we can sufficiently improve 
`log-edit-font-lock-keywords' to only render the line below actual 
headers (or summaries that very much look like header-value, I guess).

> IIUC that's a problem in Emacs's commit messages, not in vc-log-edit,
> and the presence of the "Summary:" header might actually encourage
> people to change their habit.

I've seen many times people include several entirely unrelated changes 
in one commit. How does one write a summary line for them?

If you do think that's a problem, having "Summary:" included in the 
default headers (e.g. be the sole one) might indeed improve that.

As long as point is after ":" when the buffer is created and `C-a' is 
bound to `messge-beginning-of-line', I think the main drawback would be 
that it's different from the other Git commit message edit interfaces I 
know (and people might be used to), namely Vim and Magit.

Both of them implicitly consider the first line to be the summary, and 
they indicate with highlighting when it exceeds 50 characters. In 
log-edit, users might be checking that via the mode-line and 
column-number-mode, but the presence of the header name would mess with 
that.

Adding special, summary-header-targeted highlighting would improve the 
situation.

> > Since bury-buffer doesn't have a default binding in log-edit, I think that's
> > not much of a problem. But we can follow Magit's (and message-mode's)
> > example and create a command that would do the burying the smart way (and
> > bind it to C-c C-k).
>
> Sounds good.

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?

> > Another approach would be to instead of creating a separate buffer and
> > window, output its text at the bottom of the log-edit buffer.  And
> > either make it a read-only-not-real text, or comment it out somehow
> > and remove that section before the commit is made.
>
> These could work as well, indeed.

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.