[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: trunk r115265: * lisp/vc/vc-dispatcher.el (vc-log-edit): Setup the S
From: |
Dmitry Gutov |
Subject: |
Re: trunk r115265: * lisp/vc/vc-dispatcher.el (vc-log-edit): Setup the Summary&Author headers. |
Date: |
Sat, 30 Nov 2013 00:37:43 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 |
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.