From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: File names in ChangeLog entries Date: Thu, 02 Dec 2021 02:34:32 -0500 Message-ID: References: <831r2xt32t.fsf@gnu.org> <83ilw8sa9j.fsf@gnu.org> <835ys8s1gg.fsf@gnu.org> <87czmgruyc.fsf@gnuvola.org> <83h7bsqfxh.fsf@gnu.org> <837dcnqy3q.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14102"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: stefan@marxist.se, ttn@gnuvola.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 02 08:41:11 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1msgiN-0003U9-0G for ged-emacs-devel@m.gmane-mx.org; Thu, 02 Dec 2021 08:41:11 +0100 Original-Received: from localhost ([::1]:56272 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1msgiL-0000zU-F7 for ged-emacs-devel@m.gmane-mx.org; Thu, 02 Dec 2021 02:41:09 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:47912) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1msgcF-0003hW-Jm for emacs-devel@gnu.org; Thu, 02 Dec 2021 02:34:51 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:48705) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1msgc7-0004rX-Az; Thu, 02 Dec 2021 02:34:49 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3D3DC10018A; Thu, 2 Dec 2021 02:34:36 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 6371210009E; Thu, 2 Dec 2021 02:34:34 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1638430474; bh=Iy1kg92oxSVRFDHlLpFFmo6Y2lsj9EJ0sVdh1sNUoko=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=NdUbkzEth1bi95nrsytLjRvRdwi5GoqAgcfLDm3mlJ5n0vRVZNDcpIY68qSHmui6x Xq4v218DLSbJdTppvf2cQmz56+IwrBvj36Plcf8WsQpgoZQterACnGVDbomAr8Lz20 Iz5F64LmhWkZDsGxMzcbLBNIv3JXjKpmrgijmMb+2/XlRYumVgmM2IESGaHHR7KNe8 PHin9GcajmEqqGYtQlT9A79wyc+0hoD43c0/YGOTWNiGeXL9o1HDq2qYNhOEINjuA8 mbHtQyGFfCxkCN9VrLoXl60YV5Sz+B7w4MeAoNM6L8Ect54ZPeD+Tj1BqdN4WozvEh yM3p04PmH4EGg== Original-Received: from pastel (unknown [216.154.30.173]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0CA58120176; Thu, 2 Dec 2021 02:34:34 -0500 (EST) In-Reply-To: <837dcnqy3q.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 02 Dec 2021 09:12:25 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:280717 Archived-At: > * test/src/comp-tests.el: Rework last patch > > Move `require`s out of `eval-when-compile` if the functions are called > at run-time. > Don't use #' to quote symbols (i.e. at those places where a lambda > expression couldn't be used). > Don't pre-load comp-test-45603.el and comp-test-pure.el any more. > > (comp-deftest pure): Use `declare-function` after loading `comp-test-pure.el` > to silence the byte-compiler. > > This doesn't state the file name after the summary. (Also, the lines > are too long, and will produce ugly ChangeLog entries in the tarball.) Indeed, it seems redundant to mention the file name afterwards since it's the only file affected and it's already mentioned in the summary. But I'm fine with adding the repetition here. > * lisp/emacs-lisp/subr-x.el (with-memoization): New macro > > Extracted from `cl-generic.el`. > > * lisp/emacs-lisp/cl-generic.el (cl--generic-get-dispatcher) > (cl--generic-build-combined-method, cl-generic-generalizers): Use it. > (cl--generic-with-memoization): Delete. > > This doesn't mention subr-x.el change in the "main part". Yes, this is a hybrid between the old * lisp/emacs-lisp/subr-x.el (with-memoization): New macro Extracted from `cl-generic.el`. * lisp/emacs-lisp/cl-generic.el (cl--generic-get-dispatcher) (cl--generic-build-combined-method, cl-generic-generalizers): Use it. (cl--generic-with-memoization): Delete. and the new summary+explanation+changelog format where I tried to be clever since the `subr-x` part is the core one and the other ones are just minor sidekicks. I'm fine with avoiding such cleverness. > Change ruby-align-chained-calls indendation > > * lisp/progmodes/ruby-mode.el (ruby-smie-rules): Align with the > first sibling on the previous line instead of the last (bug#32496). > > That is, before it used to be > > one.two.three > .four > > and now it is > > one.two.three > .four > > Here, the order is incorrect: the "That is" part should have been > before the "* file (func): Desc" part, not after. Not sure what I was smoking back then, indeed. > due to your self-imposed conventions: there's no need to state the > full file name, with leading directories, on the summary line. Agreed. I just need/want *some* information about which files are affected. `ruby-mode` or `subr-x` would be perfectly fine for that. > For > example, this summary: > > * lisp/emacs-lisp/subr-x.el (with-memoization): New macro > > could have been more economically written as > > New macro 'with-memoization' > > or, if you insist on mentioning the file, as > > New macro 'with-memoization' in subr-x.el I'd prefer subr-x (with-memoization): New macro which is closer to the rest of our conventions. Having the subsystem info always at the beginning is important to be able to visually scan many commits quickly without having to read&parse&understand each and every summary text. It's even more important when several commits in a row affect the same subsystem in which case the scanning is made even faster when all those commits put the subsystem info at the same place. > And in this example: > > * lisp/emacs-lisp/cl-generic.el: Try and fix bug#49866 > > (cl-generic-generalizers): Remember the specializers that match > a given value. > (cl--generic-eql-generalizer): Adjust accordingly. > > * test/lisp/emacs-lisp/cl-generic-tests.el (cl-generic-test-01-eql): > Add corresponding test. > > the file name in the summary is entirely redundant, since fixing a bug > is not necessarily related to a particular file (as the rest of the > log message clearly shows). I don't understand what you mean: the patch basically only touches `cl-generic.el`. > And the main problem with your format is that the produced ChangeLog > is ugly and hard to read, while the format we prefer is carefully > designed to produce reasonably-readable ChangeLogs. Which was why > Stefan Kangas started this discussion in the first place, AFAIU. Indeed, this discussion is related to the generation of the ChangeLog and to the fact that I have completely and totally stopped looking at them, so I'm beginning to doubt the usefulness of keeping/generating them. [ I'm curious to know who uses them still. ] But I can accommodate a convention where the file names are always clearly spelled out in the "bottom changelog section", even if that's redundant with the info in the summary line, for the benefit of generating those legacy files. Is there a chance that others might be willing to accommodate my request to always include some subsystem info in the summary line in return? Stefan