Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Konstantin Kharlamov]

On Sat, 2020-06-13 at 20:31 +0100, Basil L. Contovounesios wrote:
> Konstantin Kharlamov <hi-angel@yandex.ru> 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 :<funcname>:<file>`.

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.
>