From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Larger GC thresholds for non-interactive Emacs Date: Sat, 25 Jun 2022 13:10:19 +0800 Message-ID: <878rplwcp0.fsf@localhost> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13126"; 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: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 25 07:11:10 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 1o4y4T-0002wg-Ur for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Jun 2022 07:11:02 +0200 Original-Received: from localhost ([::1]:50764 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o4y4R-00041I-EP for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Jun 2022 01:11:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38802) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4y2k-0003JX-OY for emacs-devel@gnu.org; Sat, 25 Jun 2022 01:09:14 -0400 Original-Received: from mail-pf1-x432.google.com ([2607:f8b0:4864:20::432]:39907) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o4y2i-0006py-Qa; Sat, 25 Jun 2022 01:09:14 -0400 Original-Received: by mail-pf1-x432.google.com with SMTP id p14so4241180pfh.6; Fri, 24 Jun 2022 22:09:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=zWqfsmtdNxUNKwVqfOPlUdi/44p+h7TO1QB3GjMl/dA=; b=bo5Vt1No4i3jn2C5h3+rF8i7w8k2FBVoLG1v4ujDpBV7Kpx/JNqkgCzjNuiPCyvGzJ EZLNfsht9t2bjMLtwcvPxVDS0pIwrOrmk40+yVE8ZJdcdMAGBnY33/45e6/E1TXbR9TO PNuMoIPWQ2WbRp7xoEDhNyWl60aGwwClPsPNos3jVE23n+FR6JVRTn7dOvTNEzb+M6aM cjEGOOI+ih/G7IJwana3s2MtvxGIRbstOp/pSdHTDIMlqYceQjVJsn5EGQ7wI8EPVBvK oiiiCvaIjiskwNNrY6vmJwrCJ+zAJwmtAhz+Bo+DhHqagj2H1OmcO8RWDn8etAFbNdGZ +jLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=zWqfsmtdNxUNKwVqfOPlUdi/44p+h7TO1QB3GjMl/dA=; b=DgUAlSIUX/OX2mbEhtNRmRdnAZwiWEgDW5iN8b0io2PraiA46O3Nkkj4k9JSI+R4X7 bKbur0jJEnG3TqJRFEXM0m2zfCIGuO6ZGXeoDlp+nV64gFUhDyFH1T6bjnSDRXEx+A3j g7Tuu6ABGkoMNGDVFLSrqUCD+qqOrrOmlqlXQBq9DO9msRYIbhtKDAbiC+533IG/+jaB oPafgtGnLeu50V5MXP9im2ugatC5H/goeFuagyA5ij2C/il1R4cS1CJrkCDDdpTO0HZF rpkbK2i5sKRIjs1aQi2K78l6uzLOrVSHuV0upUb8mZ4n+LYJrTfu9TPUZp991kxm5J3x gO3g== X-Gm-Message-State: AJIora/OEfTp/6J5Dl3go1uQNOLayKCvLxsAJKrzdX82S6tpGpg02DN4 qonArZ5jdywwFZ+f/R+hXDoMX2GqGv4QKdZa/UQ= X-Google-Smtp-Source: AGRyM1ulHU4yGyspWyaLYP/nkUSNdnGKvuMZGB7s3IossAXxEysPUuZjNeBLliBKYPuhKsf4DQ2g9A== X-Received: by 2002:a63:6a85:0:b0:3fa:722a:fbdc with SMTP id f127-20020a636a85000000b003fa722afbdcmr2228249pgc.174.1656133750229; Fri, 24 Jun 2022 22:09:10 -0700 (PDT) Original-Received: from localhost ([192.161.177.252]) by smtp.gmail.com with ESMTPSA id s15-20020a17090a764f00b001df4b919937sm4799892pjl.16.2022.06.24.22.09.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Jun 2022 22:09:09 -0700 (PDT) In-Reply-To: <83r13felor.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::432; envelope-from=yantar92@gmail.com; helo=mail-pf1-x432.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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:291577 Archived-At: Eli Zaretskii writes: >> > 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. Then it raises a bigger question. Do we have anything better than email archives to archive emacs-devel? >> 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 ;-) I did expect that you at least archive emacs-devel (: >> 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? 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 >> > 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)? Of course, things will break if we change VCS, but it should not stop us from linking to commits - not linking at all is still worse. Note that I can also ask "what if we change debbugs?". Would it mean that we should not link to bug#? > 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. Sure. But false positives will not be numerous. You can expect a few max - not a big deal to check one by one. > 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. > 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? I do not imply that we should do it _instead_ of mentioning bug number. It's complementary and can be very useful (I know because I did have a hard time finding commits that fixed particular bugs). Also, bugs already need to be closed manually - that closing email directive could as well include the commit hash. > 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. Best, Ihor