From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Konstantin Kharlamov Newsgroups: gmane.emacs.devel Subject: Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers Date: Sat, 13 Jun 2020 23:24:01 +0300 Message-ID: <7e47e9a4ccb739fbd0179d2b8ae3b7b48d19e316.camel@yandex.ru> References: <87mu78huhx.fsf_-_@yahoo.com> <87k12bdgx7.fsf@yahoo.com> <87r1wi7a8o.fsf@yahoo.com> <875zdteybt.fsf@runbox.com> <87368wrvf5.fsf@yahoo.com> <86k126d83n.wl-me@enzu.ru> <83pnbyckvv.fsf@gnu.org> <4923d7e98f5ed816a7569093dbc673153adcea88.camel@yandex.ru> <87tuzezrrl.fsf@tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="103251"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.36.3 Cc: Eli Zaretskii , Emacs developers , Stefan Kangas , Dmitry Gutov To: "Basil L. Contovounesios" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 13 22:32:03 2020 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 1jkCot-000Qkj-E8 for ged-emacs-devel@m.gmane-mx.org; Sat, 13 Jun 2020 22:32:03 +0200 Original-Received: from localhost ([::1]:49894 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jkCos-00046o-Ea for ged-emacs-devel@m.gmane-mx.org; Sat, 13 Jun 2020 16:32:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54402) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jkCnt-0002ss-2B for emacs-devel@gnu.org; Sat, 13 Jun 2020 16:31:01 -0400 Original-Received: from forward101p.mail.yandex.net ([2a02:6b8:0:1472:2741:0:8b7:101]:36274) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jkCnp-00072B-V9 for emacs-devel@gnu.org; Sat, 13 Jun 2020 16:31:00 -0400 Original-Received: from mxback12o.mail.yandex.net (mxback12o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::63]) by forward101p.mail.yandex.net (Yandex) with ESMTP id A33D026425A1; Sat, 13 Jun 2020 23:24:03 +0300 (MSK) Original-Received: from sas2-b157fac3b6f2.qloud-c.yandex.net (sas2-b157fac3b6f2.qloud-c.yandex.net [2a02:6b8:c08:b282:0:640:b157:fac3]) by mxback12o.mail.yandex.net (mxback/Yandex) with ESMTP id t1yGLLQwkL-O3RW8f9K; Sat, 13 Jun 2020 23:24:03 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1592079843; bh=TgDA3Y0QOLt6bVkr809eATzRcsLLNsY5P+XF2/qHnK4=; h=In-Reply-To:Cc:To:From:Subject:Message-ID:References:Date; b=tE1gzqVc2ZzsDD5UKgM4BReXV7oguQyj6Ql7y0gKWSRvUNzyx+DsEk9chs6JUltLx EAo7F6VXLxJaNdrU654Gm9gp3cGS1kQ+gVL1+6iAm+yLPb3AxpJ+HHitCGe2BxqiuE 9Qw+YFgws+BjSCw/rqpLi1zZ1HyGtc0nwjbKHzdI= Authentication-Results: mxback12o.mail.yandex.net; dkim=pass header.i=@yandex.ru Original-Received: by sas2-b157fac3b6f2.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id bH9FT1JmIV-O2XulifE; Sat, 13 Jun 2020 23:24:02 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) In-Reply-To: <87tuzezrrl.fsf@tcd.ie> Received-SPF: pass client-ip=2a02:6b8:0:1472:2741:0:8b7:101; envelope-from=hi-angel@yandex.ru; helo=forward101p.mail.yandex.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/13 16:24:22 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:252207 Archived-At: On Sat, 2020-06-13 at 20:31 +0100, Basil L. Contovounesios wrote: > Konstantin Kharlamov writes: > > > FTR, I am all for having good commit messages. It is IMO a must have for any > > git > > project. But having a list of function names with description for each does > > not > > make one. > > FWIW, one great benefit of this list for me is that I can quickly > 'git log --grep' for all commits that mention a particular definition. > Doing the same with 'git log -G' is painfully slower and with a far > lower signal:noise ratio. You can get that purely with git by using option `-L` of gitlong. It has syntax `-L ::`. To give you example, I just looked at my recent change in python.el, and the diff says the region belongs to `python-font-lock-keywords-maximum-decoration`. So I execute: git log -L :python-font-lock-keywords-maximum- decoration:lisp/progmodes/python.el And I get a log of commits that changed that function. Git version 2.27.0 > > Instead it should be an overview of what is done, why, and how. > > That, or at the very least linking to the relevant bug/thread > discussions, is always a good thing to do and encouraged. > > > Suppose you have a patch that deduplicates the same code pattern across 34 > > functions by factoring it out to a single short function. Do you really need > > that list? > > No, in such cases there are shortcuts you can take, such as "all callers > changed". Oh, is that something new? I'm just wondering, why when I did the change to replace hex regexes with xdigit https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36167 I had to write all hundreds of functions instead of a one liner "all callers are changed"? > > I mean, sure it's a fun fact to know, but you'll have to review diff > > anyway. If anything, it only burdens you by forcing to check that each > > function > > is on the list. Commit message should reveal the intention of the changes > > (and > > perhaps, if OP thinks changes may raise questions, they should also write > > the > > reasoning). And then a reviewer gotta check (in particular) this intention > > matches the actual code. > > I doubt anyone disagrees with that. >