[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#1226: Desktop holds second Emacs session hostage; C-x C-c doesn't wo
From: |
Lawrence Mitchell |
Subject: |
bug#1226: Desktop holds second Emacs session hostage; C-x C-c doesn't work properly. |
Date: |
Wed, 22 Oct 2008 12:12:28 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) |
Alan Mackenzie wrote:
> (i) With desktop enabled, start emacs.
> (ii) Start a second emacs session.
> Emacs2 detects Emacs1 and the danger of contention over .emacs.desktop.
> It prompts thusly:
> "Warning: desktop file appears to be in use by PID 3616.
> Using it may cause conflicts. Use it anyway? (y or n)"
> (iii) Type n.
> (iv) Attempt C-c C-x.
> Emacs2 decides, because desktop is "enabled", that it wants to save a
> desktop file, and prompts:
> "Directory for desktop file: ~/"
> At this point, C-g aborts the "end Emacs" command. One now has the
> unpleasant choice of killing Emacs2 from the (operating system) console
> or typing in some random directory to dump the empty .emacs.desktop to.
> This is a bug.
I cannot reproduce with the following sequence to enable desktop:
;; start an emacs that creates a desktop file and quit
$ emacs -Q --eval '(progn (setq desktop-path (list "/tmp/"))
(desktop-save-mode 1) (desktop-read) (dired "/tmp/")
(save-buffers-kill-emacs))'
;; now start an emacs to read the desktop file (acquiring a lock)
$ emacs -Q --eval '(progn (setq desktop-path (list "/tmp/"))
(desktop-save-mode 1) (desktop-read))' &
;; start a second emacs
$ emacs -Q --eval '(progn (setq desktop-path (list "/tmp/"))
(desktop-save-mode 1) (desktop-read))'
;; This one prompts
Warning: desktop file appears to be in use by PID XXXXX.
Using it may cause conflicts. Use it anyway? (y or n)
;; I answer "n", the desktop file is not loaded.
;; Now I do save-buffers-kill-emacs and am asked:
Save desktop? (y or n)
;; I hit "n", the desktop is not saved and Emacs quits as
expected.
How have you enabled desktop in your emacs session to produce
this problem?
--
Lawrence Mitchell <wence@gmx.li>