[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.