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:52:56 +0300 Message-ID: <22650dc349758df4b0c05269c407ecade6a24181.camel@yandex.ru> References: <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> <7e47e9a4ccb739fbd0179d2b8ae3b7b48d19e316.camel@yandex.ru> <87h7ve7lox.fsf@tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="61291"; 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:54:04 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 1jkDAB-000Fnl-Ub for ged-emacs-devel@m.gmane-mx.org; Sat, 13 Jun 2020 22:54:04 +0200 Original-Received: from localhost ([::1]:33932 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jkDAB-0004Fo-1G for ged-emacs-devel@m.gmane-mx.org; Sat, 13 Jun 2020 16:54:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37124) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jkD9U-0003q3-HV for emacs-devel@gnu.org; Sat, 13 Jun 2020 16:53:20 -0400 Original-Received: from forward105p.mail.yandex.net ([77.88.28.108]:54571) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jkD9Q-0002Vu-OJ; Sat, 13 Jun 2020 16:53:19 -0400 Original-Received: from forward101q.mail.yandex.net (forward101q.mail.yandex.net [IPv6:2a02:6b8:c0e:4b:0:640:4012:bb98]) by forward105p.mail.yandex.net (Yandex) with ESMTP id 147734D40DB0; Sat, 13 Jun 2020 23:52:59 +0300 (MSK) Original-Received: from mxback1q.mail.yandex.net (mxback1q.mail.yandex.net [IPv6:2a02:6b8:c0e:39:0:640:25b3:aea5]) by forward101q.mail.yandex.net (Yandex) with ESMTP id 104DDCF4000F; Sat, 13 Jun 2020 23:52:59 +0300 (MSK) Original-Received: from vla3-5ed9a7202853.qloud-c.yandex.net (vla3-5ed9a7202853.qloud-c.yandex.net [2a02:6b8:c15:341d:0:640:5ed9:a720]) by mxback1q.mail.yandex.net (mxback/Yandex) with ESMTP id 1f0wHrmVDz-qwqagfrC; Sat, 13 Jun 2020 23:52:59 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1592081579; bh=kMiN8b9D7aw7ds+QV1o0JdCj9MzFHnyBandNkixkbGw=; h=In-Reply-To:Cc:To:From:Subject:Message-ID:References:Date; b=ZpWGi3TSiONrEl9bT1hiyAuoBVP4jBkdRxr4DVzdd7VLu/Ed63ugNsjfL57EohRCV 7CPGuqa2eASrhg8ZSviJYVE4xihA6y+hd88mzf0wMt9dQY+jChZgJjQvOJqdhsde/+ Rsjqqm+k4OU06ukYrgzOD9WsIbpeYZ0EmwIoeWg4= Authentication-Results: mxback1q.mail.yandex.net; dkim=pass header.i=@yandex.ru Original-Received: by vla3-5ed9a7202853.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id u8OU7CO2n0-qvtaWPEo; Sat, 13 Jun 2020 23:52:57 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) In-Reply-To: <87h7ve7lox.fsf@tcd.ie> Received-SPF: pass client-ip=77.88.28.108; envelope-from=hi-angel@yandex.ru; helo=forward105p.mail.yandex.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/13 16:52:59 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -30 X-Spam_score: -3.1 X-Spam_bar: --- X-Spam_report: (-3.1 / 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1, 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:252208 Archived-At: On Sat, 2020-06-13 at 21:30 +0100, Basil L. Contovounesios wrote: > Konstantin Kharlamov writes: > > > 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 > > And what if a commit message references a particular variable or > function without touching the file that they're defined in? I'm talking > about more general xrefing. I feel there's some misunderstanding. The list our discussion is about only mentions changed functions/variables. If the git message references a variable that is not changed just because it is important to mention, then, well, it should still be there, in the commit message. That's what good commit messages are for: you mention things that are important to mention ¯\_(ツ)_/¯ > > > > 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? > > It's older than I've been around these parts (~2016). > > > 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"? > > You didn't exactly. It is possible to take shortcuts depending on the > context. See the file CONTRIBUTE or (info "(standards) Change Logs") > https://www.gnu.org/prep/standards/html_node/Change-Logs.html. Oh, okay, so I read the docs, and apparently this "all callers are changed" can only be used when you use a calling convention. In my imaginary example where you factored out a code from 34 functions it would not be a calling convention, it would be a piece of code inside those functions. This is actually similar to the patch that replaces regexes to "xdigit": you have the same pattern *inside* many functions that you replace. No calling convention changes.