emacs-devel
[Top][All Lists]
Advanced

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

Re: How to stop desktop.lock file creation


From: Angelo Graziosi
Subject: Re: How to stop desktop.lock file creation
Date: Sat, 26 Mar 2022 22:30:00 +0100 (CET)

> Il 26/03/2022 06:48 Eli Zaretskii  ha scritto:
> 
>  
> > Date: Fri, 25 Mar 2022 23:53:19 +0100 (CET)
> > From: Angelo Graziosi 
> > Cc: emacs-devel@gnu.org
> > 
> > > Why do you need to delete the desktop lock file?  If you are annoyed
> > 
> > The alternative is to accept to load it or not but why should i play this 
> > game.. 
> 
> You don't need to play this game.  If you set
> desktop-load-locked-desktop to t, Emacs will unconditionally load the
> desktop even if locked, no questions asked.  Its effect is the same as
> not having the lock at all, when the process which locked the desktop
> no longer runs.

When Emacs ask for loading the desktop file it says

"Warning: desktop file appears to be in use by PID xyza.
Using it may cause conflicts.  Use it anyway? (y or n)"

So, _if it says that could be conflicts_, in my opinion, the best way to go is 
to accept it, close Emacs, restart Emacs, so that it starts in a clean state.

Why I have to to all this? Really I need this? or should I accept with the risk 
of conflicts (i am sure they do not occur!)?

> 
> > > by the question Emacs asks when you invoke it the next time, you can
> > > simply customize desktop-load-locked-desktop to the value t, then it
> > > will not ask any questions.

Yes, I could do that, but implicitly accepting the risk of conflicts (I am sure 
they do not occur!)

In all this, It seems I have to do a sterile work.

> 
> > Emacs worked the same before its introduction...
> 
> The lock was introduced in Emacs 22.2, quite some time ago.  It isn't
> a new feature.

I know this and it is what I did mean. 

If users could live without the lock file until version 22 why can't they live 
without it with the current version?

In short: really we need this lock file? really it is useful in all situations? 
Why not adding a flag to avoid its creation and that the user sets at its own 
risk?

Yes, setting desktop-load-locked-desktop to the value t is something similar to 
what I am asking but not exactly the equivalent.

In any case, thanks for all clarifications.



reply via email to

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