From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel 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 Message-ID: <52991737.9000904@yandex.ru> References: <871u1zes89.fsf@yandex.ru> <5298AA77.4060009@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1385764683 9241 80.91.229.3 (29 Nov 2013 22:38:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 Nov 2013 22:38:03 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 29 23:38:09 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VmWhM-0000rz-4p for ged-emacs-devel@m.gmane.org; Fri, 29 Nov 2013 23:38:08 +0100 Original-Received: from localhost ([::1]:50009 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VmWhL-0004bn-IS for ged-emacs-devel@m.gmane.org; Fri, 29 Nov 2013 17:38:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38087) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VmWh9-0004aw-RG for emacs-devel@gnu.org; Fri, 29 Nov 2013 17:38:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VmWh1-00089Q-C5 for emacs-devel@gnu.org; Fri, 29 Nov 2013 17:37:55 -0500 Original-Received: from mail-we0-x233.google.com ([2a00:1450:400c:c03::233]:50726) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VmWh1-00089I-1H for emacs-devel@gnu.org; Fri, 29 Nov 2013 17:37:47 -0500 Original-Received: by mail-we0-f179.google.com with SMTP id q59so9678361wes.24 for ; Fri, 29 Nov 2013 14:37:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=YQFjrXLX+YddqM+Z3+uHk8Kq3qChcEfKqYyW+pKgS4c=; b=LU9bqfOKEgtGK9+8SSsk3A/5EXy752YCOYO5vBQkSXVyYR3g1uEyWlffvJZblSI22B cwTjmruTAmZn1GJ0HofA33JdjFhaFG/oB2r1QXnAaposjsKEzV79mAx5e/IhzA6hVTL0 zzfBmQepBKMit9YWkITRV1aMivbo9eUCMGXe4j//gWKpKdy+c2djtvo4pv3okIHM+IPG vpmWAv/YiZ5A/6CswYuPtNWz8cfosFvt1OMUYwsYQkrCEIc7AWi29buSOynetRWt2rvR NiOGMFHeeFcDeHLf7+gmvnrUbvlML7v6BQsG6ng2AXFWx7m+6q3eaJi4oIicSt0AAZba 5Jwg== X-Received: by 10.180.106.200 with SMTP id gw8mr8671414wib.50.1385764665842; Fri, 29 Nov 2013 14:37:45 -0800 (PST) Original-Received: from [192.168.10.2] (83-43-131.netrun.cytanet.com.cy. [83.168.43.131]) by mx.google.com with ESMTPSA id o9sm26947597wib.10.2013.11.29.14.37.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 Nov 2013 14:37:45 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c03::233 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:165908 Archived-At: 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.