[Top][All Lists]

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

bug#1474: 23.0.60; desktop.el don't check if pid in his lock file is alw

From: Thierry Volpiatto
Subject: bug#1474: 23.0.60; desktop.el don't check if pid in his lock file is always in use
Date: Wed, 03 Dec 2008 11:08:35 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

"Juanma Barranquero" <address@hidden> writes:

> On Wed, Dec 3, 2008 at 09:47, Thierry Volpiatto
> <address@hidden> wrote:
>> I am sorry but I don't understand why emacs would find a process on
>> another computer.
> No, I'm saying that Emacs *won't* find a process in another computer.
>> In which case ?
> The user can customize desktop.el so the desktop file (and desktop
> file lock) are anywhere, even in a shared directory in a remote disk.
Ok i understand now.
In this case, may be a variable can be set:

* Use a remote desktop ==> use the .emacs.desktop.lock like the actual

* Use a local desktop ==> in this case check if pid exist.

(i think local desktop is the most common case)

>> I just want emacs to check if the process that is in the lock file is
>> own by another emacs process.
> Yes, I understand. And I'm saying that in the presence of distributed
> filesystems, you cannot guarantee that a desktop lock file in a local
> disk is owned by a local process, or that a local Emacs is saving the
> desktop locally.
>> * If no emacs process with this pid is found ==> load desktop
>> * If an emacs process with this pid is found ==> ask (default) if we load
>>  desktop or not
>> Actually when the .emacs.desktop.lock is found, emacs lock desktop and
>> ask if we want to use the desktop file, even if the pid that is in the
>> file is no more in use by an emacs session.
> I share the sentiment. In fact, I do exactly that in my .emacs.
> But the point of the desktop locking mechanism is protecting the user;
> automatically overwriting the desktop is against that idea.
>   Juanma

A + Thierry Volpiatto
Location: Saint-Cyr-Sur-Mer - France

reply via email to

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