From: Angelo Graziosi <angelo.g0@libero.it>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: How to stop desktop.lock file creation
Date: Sat, 26 Mar 2022 22:30:00 +0100 (CET) [thread overview]
Message-ID: <1611306500.320421.1648330200906@mail1.libero.it> (raw)
In-Reply-To: <83ils1b6x2.fsf@gnu.org>
> 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.
next prev parent reply other threads:[~2022-03-26 21:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-24 22:33 How to stop desktop.lock file creation Angelo Graziosi
2022-03-25 6:34 ` Eli Zaretskii
2022-03-25 22:53 ` Angelo Graziosi
2022-03-26 5:48 ` Eli Zaretskii
2022-03-26 21:30 ` Angelo Graziosi [this message]
2022-03-27 5:03 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1611306500.320421.1648330200906@mail1.libero.it \
--to=angelo.g0@libero.it \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.