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.bugs Subject: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains Date: Wed, 07 Jul 2021 21:42:28 +0300 Message-ID: <83zguydkyz.fsf@gnu.org> References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <834kd6f1dw.fsf@gnu.org> <87h7h6m1jh.fsf@gnus.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27695"; mail-complaints-to="usenet@ciao.gmane.io" Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jul 07 20:43:31 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1m1CWB-0006yN-55 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 07 Jul 2021 20:43:31 +0200 Original-Received: from localhost ([::1]:49124 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m1CWA-0004pv-7Z for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 07 Jul 2021 14:43:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34534) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m1CVj-0004pD-LS for bug-gnu-emacs@gnu.org; Wed, 07 Jul 2021 14:43:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41911) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m1CVh-0000KD-PI for bug-gnu-emacs@gnu.org; Wed, 07 Jul 2021 14:43:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1m1CVh-00079V-O2 for bug-gnu-emacs@gnu.org; Wed, 07 Jul 2021 14:43:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 07 Jul 2021 18:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49261 X-GNU-PR-Package: emacs Original-Received: via spool by 49261-submit@debbugs.gnu.org id=B49261.162568334927440 (code B ref 49261); Wed, 07 Jul 2021 18:43:01 +0000 Original-Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 18:42:29 +0000 Original-Received: from localhost ([127.0.0.1]:53457 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1CVA-00078V-UP for submit@debbugs.gnu.org; Wed, 07 Jul 2021 14:42:29 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:36666) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1CV9-00078F-7C for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 14:42:27 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:41780) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m1CV1-0000BZ-Is; Wed, 07 Jul 2021 14:42:21 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3344 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 1m1CV1-00018Y-6a; Wed, 07 Jul 2021 14:42:19 -0400 In-Reply-To: <87h7h6m1jh.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 07 Jul 2021 20:17:22 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:209613 Archived-At: > From: Lars Ingebrigtsen > Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org > Date: Wed, 07 Jul 2021 20:17:22 +0200 > > > Also, do we ever need this during loadup? Because before files.el is > > loaded by loadup, this function will not be available, so > > unconditionally calling it from C without protection, not even > > safe_call or somesuch, is not safe. > > I'll try doing a "make bootstrap"... Even if it currently works, it's unsafe, IMO, to not have any protection there. No one will remember that we rely on this not being called early enough. > > Last, but not least: do we care that now locking a file will cons > > strings, even with the default value of lock-file-name-transforms? > > That sounds like we are punishing the vast majority of users for the > > benefit of the few who need the opt-in behavior. Should we perhaps > > avoid consing strings, or maybe even calling Lisp altogether, under > > the default value of that option? > > Hm... I think for simplicity's sake, it makes sense to always call the > Lisp code. Having two places where we insert ".#" into a file name just > seems error prone, long term. My point is that this simplicity comes at a price. We've been consistently moving code from C primitives to Lisp, and by doing that significantly increase the consing during even the simplest editing operations. All this consing adds up, with the result that Emacs nowadays produces much more garbage, which then triggers frequent GC cycles, which slow down Emacs. It's a small wonder we see so many people out there raising the GC threshold to dangerous levels. So I'm asking whether the simplicity justifies the costs, here and elsewhere.