bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#66993: [PATCH] project.el: avoid asking user about project-list-file


From: Eli Zaretskii
Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock
Date: Wed, 08 Nov 2023 14:22:31 +0200

> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Tue, 07 Nov 2023 16:28:04 -0500
> 
> There are several features which will cause Emacs to frequently call
> project-current, and therefore call project-remember-project, and
> therefore sometimes call project--write-project-list whenever a new
> project is seen.

Why does project-current immediately writes the list to the file?  Why
cannot it keep the information in memory and write it only when the
session ends, or at some random rare opportunity?

> - project-uniquify-dirname-transform will call this for each new
>   buffer
> 
> - project-mode-line will call this on mode-line update
> 
> - My own private project-watch will call this based on file-notify
>   events.

Ouch! this doesn't sound like a clean implementation to me.  Writing
something to a file from mode-line update? or when a new buffer is
created?  Why cannot we come up with a cleaner implementation?

> There's no correct answer the user can give to ask-user-about-lock:
> either way, one of the Emacs instances will have its project-list-file
> update lost.  So let's not even bother prompting the user: just do
> nothing if project-list-file is currently locked.

Sorry, that cannot be TRT.  We cannot second-guess what the user wants
to do in this case, and claim we are always right.

> In the long run, the update doesn't actually get lost, because the
> Emacs instance will probably make the same project-list-file update
> again a few seconds later due to a later call to project-current.  So
> this doesn't lose anything.

One more reason not to write the changes upon each change.  Or at
least detect that the file is locked, and schedule update at a later
time, or something.  Ideally, we should only write the file at exit.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]