bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> 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.