From: Dmitry Gutov <dgutov@yandex.ru>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
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 [thread overview]
Message-ID: <52991737.9000904@yandex.ru> (raw)
In-Reply-To: <jwveh5zcfm3.fsf-monnier+emacs@gnu.org>
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.
next prev parent reply other threads:[~2013-11-29 22:37 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E1VlqjS-0006O3-Fn@vcs.savannah.gnu.org>
2013-11-29 4:39 ` trunk r115265: * lisp/vc/vc-dispatcher.el (vc-log-edit): Setup the Summary&Author headers Dmitry Gutov
2013-11-29 13:33 ` Stefan Monnier
2013-11-29 14:53 ` Dmitry Gutov
2013-11-29 17:04 ` Stefan Monnier
2013-11-29 22:37 ` Dmitry Gutov [this message]
2013-11-30 2:29 ` Stefan Monnier
2013-11-30 16:02 ` Dmitry Gutov
2013-12-01 21:10 ` Stefan Monnier
2013-12-02 2:40 ` Dmitry Gutov
2013-12-02 13:53 ` Stefan Monnier
2013-12-02 23:02 ` Dmitry Gutov
2013-12-03 0:56 ` Leo Liu
2013-12-03 3:06 ` Stefan Monnier
2013-12-04 0:38 ` Dmitry Gutov
2013-12-03 2:17 ` Dmitry Gutov
2013-12-03 3:09 ` Stefan Monnier
2013-12-04 0:43 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52991737.9000904@yandex.ru \
--to=dgutov@yandex.ru \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.