Re: Larger GC thresholds for non-interactive Emacs

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: owinebar@gmail.com,  larsi@gnus.org,  monnier@iro.umontreal.ca,
>   mattiase@acm.org,  theophilusx@gmail.com,  rms@gnu.org,  acm@muc.de,
>   emacs-devel@gnu.org
> Date: Sat, 25 Jun 2022 13:10:19 +0800
> 
> >> > For starters, display of the archives by thread doesn't work in that
> >> > case as expected: you are given the illusion that the thread ends.
> >> 
> >> Are you referring to lists.gnu.org thread display interface?
> >
> > I mean it, but also every other mailing list software I ever used.
> > They all have these problems, and some more than others.
> >
> >> If it is as buggy as you are describing, why don't you file a bug
> >> report the relevant ML and get the problem fixed?
> >
> > Because I don't believe this is fixable in practice.
> 
> Then it raises a bigger question. Do we have anything better than email
> archives to archive emacs-devel?

I don't know of any.

> >> https://yhetil.org/emacs-devel/_/text/help/
> >
> > How is it significantly better?
> 
> Search is more flexible because it at least allows search by date and by
> some more email fields.
> Compare search section of https://yhetil.org/emacs-devel/_/text/help/
> and https://lists.gnu.org/archive/cgi-bin/namazu.cgi?idxname=bug-gnu-emacs

I don't see anything that would make the search more efficient.  In
particular, all the different method of searching for matches in
various parts of the message or in practice of no help at all, since I
basically have no idea where the keyword appeared when I start
searching.

> Note that I can also ask "what if we change debbugs?". Would it mean
> that we should not link to bug#?

The bug number gives you a quick way of reaching the bug discussion in
the email archives of bug-gnu-emacs, and in debbugs itself.  These
will remain available even if we switch away from debbugs as our issue
tracker.  So the bug number is definitely a good thing to have in the
logs.

> > And in any case, the trigger for this discussion was the situation
> > where you want to answer questions like "why did Emacs stop using sbrk
> > on GNU/Linux", in which case there's no commit ID to search for.
> 
> I implied using git log search to identify the relevant commits.

That doesn't work well IME.  Would you mind walking me though using
that when trying to answer the above question about sbrk?

> > These measures don't really work without a gatekeeper.  Which we don't
> > have, and probably never will.
> 
> I do not think that it is so much of an issue. Your argument would also
> apply, e.g. to using double space between sentences in the commit
> messages or to following log entry format. Yet people do follow these
> conventions because they are documented in CONTRIBUTE file and because
> non-compliant commits are being scolded. Not 100%, but frequently enough
> to make the conventions useful.

Two spaces between sentences is simple enough that we have several
eyes looking for that and fixing problems post-mortem.  And yet we
still have quite a few of them, just try searching in the Emacs tree.
Conventions that are harder to spot are followed even less.

As a matter of fact, I have hard time making sure each commit that has
a bug number mentions that number in the commit log message.