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: Sat, 25 Jun 2022 09:03:28 +0300 Message-ID: <83tu89b7pr.fsf@gnu.org> References: <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> <83r13felor.fsf@gnu.org> <878rplwcp0.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32219"; 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 Sat Jun 25 08:08:54 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 1o4yyS-0008C3-N4 for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Jun 2022 08:08:52 +0200 Original-Received: from localhost ([::1]:45376 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o4yyR-000703-4H for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Jun 2022 02:08:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45664) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4ytR-0005dd-E4 for emacs-devel@gnu.org; Sat, 25 Jun 2022 02:03:41 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:53026) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4ytQ-0002no-5n; Sat, 25 Jun 2022 02:03:40 -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=5cfP4DxolurC4MrApKqXhQUS+ou707SCUmwxljlWcE0=; b=m+jdOVDY5sOi O724cgC+bhrfLAZZtSbE2SbGgKyKAG4efOqsMVP/ykH2G5m1LxPq5i2/XxID4PjfbOK1eKmeGFOGz Yl6R4sHwWmYl+nThxV11MjNMtGl9o4eImWThvHwkkAuOyAxZZNAzHK7BEvT6/LkSVBL0ILKGAJVak Y3LlIsR0LuG+cDZ4uDghFlAk9kX974JvjxO7lbceNKIDpFFgBNFFSRGNN0BfO1THG32q52m+DfFh+ kpGfyLmHFQ66LH6zPrxidNH53FWXFD525xtuS+1jzVJaVX7U0UVlSrlSwITzuvh7aLhk3Uhksbsrc e1Hj511iomzSHd6AHILnBQ==; Original-Received: from [87.69.77.57] (port=4445 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 1o4ytI-0003t2-T9; Sat, 25 Jun 2022 02:03:33 -0400 In-Reply-To: <878rplwcp0.fsf@localhost> (message from Ihor Radchenko on Sat, 25 Jun 2022 13:10:19 +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:291580 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: 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.