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 21:30 +0100, Basil L. Contovounesios wrote:
> Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> 
> > 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
> 
> 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.