From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Larger GC thresholds for non-interactive Emacs Date: Thu, 23 Jun 2022 13:08:52 +0300 Message-ID: <83r13felor.fsf@gnu.org> References: <87sfo4epeo.fsf@localhost> <87bkurrc5e.fsf@localhost> <87bkur72b7.fsf@gnus.org> <874k0j40e7.fsf@gnus.org> <871qvm16he.fsf@gnus.org> <83a6aanm5j.fsf@gnu.org> <87o7yozzj0.fsf@gnus.org> <83k098kg6c.fsf@gnu.org> <8335fvg8kz.fsf@gnu.org> <87pmizrgoi.fsf@localhost> <83zgi3espf.fsf@gnu.org> <87pmizajtv.fsf@localhost> <83y1xneqif.fsf@gnu.org> <87mte3ah08.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16841"; mail-complaints-to="usenet@ciao.gmane.io" 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 To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jun 23 12:36:04 2022 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 1o4KBv-00048O-TX for ged-emacs-devel@m.gmane-mx.org; Thu, 23 Jun 2022 12:36:03 +0200 Original-Received: from localhost ([::1]:52024 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o4KBu-0000BF-Nt for ged-emacs-devel@m.gmane-mx.org; Thu, 23 Jun 2022 06:36:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52650) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4Jls-0002Zw-B3 for emacs-devel@gnu.org; Thu, 23 Jun 2022 06:09:08 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:39900) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4Jlr-0002mZ-3y; Thu, 23 Jun 2022 06:09:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=sVsKoQt9FjP2T/HFrJ0MKJnTHYNnzvwRdURHCHfdbv4=; b=R4/TQt53q87M yXVgju0ZcjtAjaD3iscySgZHjRvvOOwXATj/QUMO1+JKm63gg83ND4LHsGIKyam/KPEyMN0APWq8D o/A2gwrdT8jjXnwgPykaZRl86+Hz+nAF0eKyelb+GKSnr9LPtHNB+4OzxLgGk5g/gHghnm9SjKeXS CWFg6gX2l8rLIYnoiLS/xoGUxLC6KL5kG6YL1hMtLVXfTZJgqDbb4/l4Jdn6DSfqvr/RtoqD/aW4f wpxGdx6uj1HGM527jZxtUbFuL8Kh9VtPc5oovYoaV8Hv/82439AEP0Ur7CndUq/MOeYIthHrGhMC6 aQW3VB5/N9x138t4zwzstw==; Original-Received: from [87.69.77.57] (port=1278 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4Jlm-0003PI-I1; Thu, 23 Jun 2022 06:09:03 -0400 In-Reply-To: <87mte3ah08.fsf@localhost> (message from Ihor Radchenko on Thu, 23 Jun 2022 17:03:35 +0800) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:291534 Archived-At: > From: Ihor Radchenko > 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: Thu, 23 Jun 2022 17:03:35 +0800 > > Eli Zaretskii writes: > > >> Can't the past discussions be directly updated by sending an extra email > >> that links back to the new commit? > > > > You mean, rely on search engines to find an addition to a discussion > > made many years later? My experience with searching the archives is > > that it many times fails when the discussion crosses the year mark. > > 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. > There are alternatives. I personally prefer to search using local > maildir copy via notmuch. I believe that gnus should also be able to > search across the maildir. I have local search set up as well, but that only works on messages I decided to archive locally. If you think I'm archiving every forum in which I participate, think again ;-) > Also, there is https://yhetil.org/ with somewhat better search and > display interface (IMHO). See > https://yhetil.org/emacs-devel/_/text/help/ How is it significantly better? > > Searching the archives also has the disadvantage that in many cases > > it's hard to know what are the keywords that would find the discussion > > efficiently (i.e. without drowning it in thousands of irrelevant > > messages). > > When I was saying "links back to the new commit", I was referring to the > unique commit number. Searching exact match will not give false > positives then. What do you do with this when we change the VCS (which happened twice already)? And even if you are only talking about Git SHA signatures, the "no false positives" is not guaranteed, when messages provide only the 7-digit SHA. 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. Moreover, I don't understand the proposal in general: are you suggesting that every commit related to a discussion would somehow send a message to the thread with the commit ID? If so, how would this work better than our (constantly failing) practice of mentioning the bug number in the commit log messages? These measures don't really work without a gatekeeper. Which we don't have, and probably never will.