bug#21833: 24.4; desktop-kill, which is interactive, is in kill-emacs-hook

bug#21833: 24.4; desktop-kill, which is interactive, is in kill-emacs-hook

[Michael Arntzenius]

[-- Attachment #1: Type: text/plain, Size: 8169 bytes --]

Recipe:

emacs -Q
M-x desktop-save-mode
C-h v kill-emacs-hook
M-x kill-emacs

Expected behavior: emacs is killed.
Actual behavior: asked "Save desktop? (y or n)"

The same behavior occurs if I send emacs SIGTERM. In particular, this
behavior occurs if an `emacs --daemon' instance with no running clients
is sent SIGTERM, which results in it... not quitting. Sending SIGTERM
twice kills it, but this is very idiosyncratic behavior.

In GNU Emacs 24.4.1 (x86_64-pc-linux-gnu, GTK+ Version 3.14.9)
 of 2015-03-21 on kissel, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.11701000
System Description:    Ubuntu 15.04

Configured using:
 `configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.4/site-lisp:/usr/share/emacs/site-lisp
 --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
 --libexecdir=/usr/lib --localstatedir=/var/lib
 --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.4/site-lisp:/usr/share/emacs/site-lisp
 --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars
 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat
 -Werror=format-security -Wall' CPPFLAGS=-D_FORTIFY_SOURCE=2
 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro''

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Emacs-Lisp

Minor modes in effect:
  shell-dirtrack-mode: t
  paredit-mode: t
  rainbow-delimiters-mode: t
  whitespace-mode: t
  which-function-mode: t
  iswitchb-mode: t
  desktop-save-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  temp-buffer-resize-mode: t
  column-number-mode: t
  line-number-mode: t

Recent input:
M-x r e p o r t e - <backspace> <backspace> - e m <tab>
<return> C-g M-x s u m m <tab> C-g M-x r e p o r t
- e m <tab> <return> d e s k t o p SPC <backspace>
M-b k i l l - C-g C-h f d e s k t o p - k i l l <return>
C-h v d <backspace> k i l l - e m <tab> h o <tab> <return>
C-' C-n C-n C-e C-a C-e C-M-' C-; r j e C-; C-f . e
m <tab> / i n i <tab> <return> C-a C-s C-g C-; r s
e C-e C-p C-n C-s ? e C-a C-; r j e C-e C-; e C-; C-g
C-a C-e C-; C-e C-; r j e C-a C-e C-r s e t - r e g
i s t C-e C-; r i p C-/ C-a C-e C-; C-s M-x r e p o
r t - e m <tab> <return>

Recent messages:
 '(desktop-load-locked-desktop t)"
Mark saved where search started
jump-to-register: Register doesn't contain a buffer position or
configuration
kmacro-call-macro: No kbd macro has been defined
C-x C-g is undefined
(file . "~/.emacs.d/init.el")
Mark saved where search started
Mark set
Undo!
(No changes need to be saved)

Load-path shadows:
/home/rntz/.emacs.d/elpa/haml-mode-20141213.920/haml-mode hides
~/.emacs.d/elisp/haml-mode
/home/rntz/.emacs.d/elpa/sass-mode-20141219.324/sass-mode hides
~/.emacs.d/elisp/sass-mode
/home/rntz/.emacs.d/elpa/yaml-mode-20141125.37/yaml-mode hides
~/.emacs.d/elisp/yaml-mode
/home/rntz/.emacs.d/elpa/markdown-mode-20150121.1229/markdown-mode hides
~/.emacs.d/elisp/markdown-mode
/home/rntz/.emacs.d/elpa/paredit-20150217.713/paredit hides
~/.emacs.d/elisp/paredit
/usr/share/emacs/24.4/site-lisp/debian-startup hides
/usr/share/emacs/site-lisp/debian-startup
~/.emacs.d/elisp/loaddefs hides /usr/share/emacs/24.4/lisp/loaddefs
/usr/share/emacs24/site-lisp/dictionaries-common/flyspell hides
/usr/share/emacs/24.4/lisp/textmodes/flyspell
/usr/share/emacs24/site-lisp/dictionaries-common/ispell hides
/usr/share/emacs/24.4/lisp/textmodes/ispell
/home/rntz/.emacs.d/elpa/prolog-1.22/prolog hides
/usr/share/emacs/24.4/lisp/progmodes/prolog

Features:
(shadow sort mail-extr misearch multi-isearch eieio-opt emacsbug message
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mail-utils add-log server sml-mode julia-mode ert debug sgml-mode
tex-mode rst sass-mode haml-mode js css-mode ruby-mode simple-tabs
elm-mode elm-map elm-preview elm-compile elm-repl elm-util elm-font-lock
elm-indentation elm-indent elm-string js3-mode js3-parse js3-browse
js3-highlight js3-ast js3-messages js3-scan js3-util js3-vars
js3-externs python json cider-mode cider-eldoc eldoc cider-interaction
cider-doc org-table cider-test cider-stacktrace cider-client
nrepl-client queue cider-util ewoc clojure-mode conf-mode markdown-mode
slime arc-mode archive-mode hyperspec agda2-mode derived agda2-queue
agda2-abbrevs skeleton agda2-highlight agda2 agda-input quail help-mode
annotation eri pp rust-mode cc-langs cc-mode cc-fonts cc-guess cc-menus
cc-cmds lua-mode rx make-mode utop utop-minor-mode caml tuareg_indent
tuareg speedbar sb-image ezimage dframe caml-help caml-types caml-emacs
scheme racket-mode racket-collection tq ido racket-profile racket-edit
hideshow racket-complete racket-repl racket-util racket-common
racket-indent racket-font-lock racket-keywords-and-builtins thingatpt
racket-custom dash haskell-indent superword subword haskell-font-lock
inf-haskell haskell-cabal haskell-utils haskell-decl-scan haskell-mode
haskell-string haskell-sort-imports haskell-align-imports haskell-compat
haskell-complete-module flymake etags compile dabbrev haskell-customize
vc-git org-element org-rmail org-mhe org-irc org-info org-gnus
org-docview doc-view jka-compr image-mode org-bibtex bibtex org-bbdb
org-w3m org org-macro org-footnote org-pcomplete org-list org-faces
org-entities noutline outline easy-mmode org-version ob-emacs-lisp ob
ob-tangle ob-ref ob-lob ob-table ob-exp org-src ob-keys ob-comint
ob-core ob-eval org-compat org-macs org-loaddefs find-func cal-menu
calendar cal-loaddefs dired-aux sh-script smie executable tramp-cache
tramp-sh tramp tramp-compat auth-source eieio eieio-core gnus-util
mm-util mail-prsvr password-cache tramp-loaddefs trampver shell
pcomplete comint ring format-spec buffer-rename-relative paredit
rainbow-delimiters whitespace which-func imenu paren time-date iswitchb
icomplete hl-line desktop frameset cus-start cus-load ansi-color cstuff
cc-styles cc-align cc-engine cc-vars cc-defs browse-url dired-details+
dired-details dired-x wdired dired dired-sort-map ls-lisp byte-opt
bytecomp byte-compile cconv mode-line-host-name advice autoload help-fns
lisp-mnt ctags-autoloads dot-mode-autoloads edmacro kmacro
js3-mode-autoloads git-commit-mode-autoloads pkg-info-autoloads
epl-autoloads prolog-autoloads queue-autoloads s-autoloads info easymenu
slime-autoloads stupid-indent-mode-autoloads cl-macs package epg-config
proof-site proof-autoloads pg-vars mmm-auto mmm-vars mmm-compat cl gv
cl-loaddefs cl-lib tooltip electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
gfilenotify dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 16 685833 56003)
  (symbols 48 53292 0)
  (miscs 40 13732 2490)
  (strings 32 149124 24011)
  (string-bytes 1 4249422)
  (vectors 16 64105)
  (vector-slots 8 2219937 150055)
  (floats 8 262 561)
  (intervals 56 25805 0)
  (buffers 960 440)
  (heap 1024 83840 2089))

[-- Attachment #2: Type: text/html, Size: 8931 bytes --]

bug#21833: 24.4; desktop-kill, which is interactive, is in kill-emacs-hook

[Stelian Iancu]

I think this might be the correct behavior.

The documentation of `desktop-save-mode' says the following:

When Desktop Save mode is enabled, the state of Emacs is saved from
one session to another.  In particular, Emacs will save the desktop when
it exits (this may prompt you; see the option `desktop-save').  The next
time Emacs starts, if this mode is active it will restore the desktop.

The default value of `desktop-save' is `ask-if-new'. Since you started 
Emacs with -Q, I guess there was no desktop file loaded and that's why 
you get the prompt.

Can somebody more knowledgeable than me comment?

Thanks,
Stelian

bug#21833: 24.4; desktop-kill, which is interactive, is in kill-emacs-hook

[Glenn Morris]

The point is that kill-emacs-hook is not supposed to contain interactive
things.

bug#21833: 24.4; desktop-kill, which is interactive, is in kill-emacs-hook

[Stelian Iancu]

On 12/11/15 21:11, Glenn Morris wrote:
>
> The point is that kill-emacs-hook is not supposed to contain interactive
> things.
>

Thanks for the clarification.

I've had a look at the code and desktop-kill is added to the 
kill-emacs-hook in desktop.el:

(unless noninteractive
(add-hook 'kill-emacs-hook 'desktop-kill))

So I guess the fix would be to remove these two lines, right?

Thanks,
Stelian

bug#21833: 24.4; desktop-kill, which is interactive, is in kill-emacs-hook

[Eli Zaretskii]

> From: Stelian Iancu <si@siancu.net>
> Date: Thu, 12 Nov 2015 21:24:36 +0100
> Cc: 21833@debbugs.gnu.org
> 
> On 12/11/15 21:11, Glenn Morris wrote:
> >
> > The point is that kill-emacs-hook is not supposed to contain interactive
> > things.
> >
> 
> Thanks for the clarification.
> 
> I've had a look at the code and desktop-kill is added to the 
> kill-emacs-hook in desktop.el:
> 
> (unless noninteractive
> (add-hook 'kill-emacs-hook 'desktop-kill))
> 
> So I guess the fix would be to remove these two lines, right?

Not exactly.  From the ELisp manual:

   -- Variable: kill-emacs-hook
       This normal hook is run by `kill-emacs', before it kills Emacs.

       Because `kill-emacs' can be called in situations where user
       interaction is impossible (e.g., when the terminal is
       disconnected), functions on this hook should not attempt to
       interact with the user.  If you want to interact with the user
       when Emacs is shutting down, use `kill-emacs-query-functions',
       described below.

So I think the hook should be added to kill-emacs-query-functions,
since we still want to ask the user that question, when appropriate.

bug#21833: 24.4; desktop-kill, which is interactive, is in kill-emacs-hook

[Glenn Morris]

>> (unless noninteractive
>> (add-hook 'kill-emacs-hook 'desktop-kill))

There are several other instances of this form.
Someone should check them all, and consider what TRT to do is when Emacs
isn't in batch mode but can't interact.

Ref bug#13697 and 8137, and commit 845fc5e5.

bug#21833: 24.4; desktop-kill, which is interactive, is in kill-emacs-hook

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 513 bytes --]

I think the key words are "should not". For example, emacs-lock sets both
kill-emacs-hook and kill-emacs-query-functions. If the user goes to the
trouble of exit-locking a buffer, they won't be happy if M-x kill-emacs
bypasses the protection.

I think something similar applies to desktop. Setting up a desktop can be
time consuming. Best to err in the side of safety.

After all, kill-emacs doesn't even guarantee that it will kill Emacs.
Nothing forbids doing

(add-hook 'kill-emacs-hook (lambda () (error ""))

[-- Attachment #2: Type: text/html, Size: 654 bytes --]

bug#21833: 24.4; desktop-kill, which is interactive, is in kill-emacs-hook

[Glenn Morris]

The point is, kill-emacs-hook can run in situations where it is
impossible for Emacs to interact with the user.
Any yes-or-no-p questions will never be answered.
Emacs will hang and have to be forcibly killed.
Exactly as it says in the OP.

So don't put anything on kill-emacs-hook that needs an interactive
response from the user. Decide on a sensible non-interactive behaviour,
and for the interactive case use kill-emacs-query-functions.
The documentation seems clear to me.

bug#21833: 24.4; desktop-kill, which is interactive, is in kill-emacs-hook

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 1356 bytes --]

On Fri, Nov 13, 2015 at 12:38 AM, Glenn Morris <rgm@gnu.org> wrote:

> The point is, kill-emacs-hook can run in situations where it is
> impossible for Emacs to interact with the user.
> Any yes-or-no-p questions will never be answered.
> Emacs will hang and have to be forcibly killed.
> Exactly as it says in the OP.

Yes, I understand. My point being, kill-emacs does *not* guarantee that it
will kill Emacs (as my simple hook example shows). It could be designed to
offer that guarantee, but it doesn't currently. So the possibility of
having to forcibly kill Emacs is always there.

> So don't put anything on kill-emacs-hook that needs an interactive
> response from the user. Decide on a sensible non-interactive behaviour,
> and for the interactive case use kill-emacs-query-functions.
> The documentation seems clear to me.

I'd agree, but in some cases, the "sensible non-interactive behaviour" is
just to abort killing Emacs (that's what emacs-lock does, for example, if
it has one or more exit-locked buffers). Which is conceptually different of
asking the user and never getting an answer...? OK, it is, but Emacs will
"hang and have to be forcibly killed" anyway. Same difference.

I suppose what I'm trying to say is that "should not" is a recommendation,
nothing more and nothing less. But certainly I won't argue this point to
exhaustion.

[-- Attachment #2: Type: text/html, Size: 1640 bytes --]

bug#21833: 24.4; desktop-kill, which is interactive, is in kill-emacs-hook

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 581 bytes --]

My last comment on this issue (don't want to drag it further):

When the OP says;

  emacs -Q
  M-x desktop-save-mode
  C-h v kill-emacs-hook
  M-x kill-emacs

  Expected behavior: emacs is killed.
  Actual behavior: asked "Save desktop? (y or n)"​

I say:

  emacs -Q
  (require 'emacs-lock) <C-x C-e>
  (emacs-lock-mode 'exit) <C-x C-e>
  M-x kill-emacs <RET>

  Expected behavior: emacs is killed ???
  Actual behavior: => Emacs cannot exit because buffer "*scratch*" is locked

Because I use emacs-lock and I certainly wouldn't expect it to be killed.

[-- Attachment #2: Type: text/html, Size: 855 bytes --]

bug#21833: 24.4; desktop-kill, which is interactive, is in kill-emacs-hook

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 13 Nov 2015 00:53:56 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, 21833@debbugs.gnu.org, Stelian Iancu <si@siancu.net>
> 
> > So don't put anything on kill-emacs-hook that needs an interactive
> > response from the user. Decide on a sensible non-interactive behaviour,
> > and for the interactive case use kill-emacs-query-functions.
> > The documentation seems clear to me.
> 
> I'd agree, but in some cases, the "sensible non-interactive behaviour" is just
> to abort killing Emacs

Why not decide that the sensible non-interactive behavior is to behave
as if the answer is NO?  Can you think up a use cases where this would
be terribly wrong?

FWIW, IME, whenever I see this question (interactively, of course),
the correct answer is always NO.  So even if the above strategy errs,
it does so in a very small fraction of use cases, at least IME.

bug#21833: 24.4; desktop-kill, which is interactive, is in kill-emacs-hook

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 13 Nov 2015 01:27:32 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, 21833@debbugs.gnu.org, Stelian Iancu <si@siancu.net>
> 
> I say:
> 
> emacs -Q
> (require 'emacs-lock) <C-x C-e>
> (emacs-lock-mode 'exit) <C-x C-e>
> M-x kill-emacs <RET>
> 
> Expected behavior: emacs is killed ???
> Actual behavior: => Emacs cannot exit because buffer "*scratch*" is locked
> 
> Because I use emacs-lock and I certainly wouldn't expect it to be killed.

Then I guess you are saying that in the case of emacs-lock there's no
similar bug?

I'll probably agree (I don't use that package), but why does it have
to tell us that desktop.el should behave the same?  It doesn't have
the same purpose, right?

bug#21833: 24.4; desktop-kill, which is interactive, is in kill-emacs-hook

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: Stelian Iancu <si@siancu.net>,  21833@debbugs.gnu.org
> Date: Thu, 12 Nov 2015 16:38:48 -0500
> 
> 
> >> (unless noninteractive
> >> (add-hook 'kill-emacs-hook 'desktop-kill))
> 
> There are several other instances of this form.
> Someone should check them all, and consider what TRT to do is when Emacs
> isn't in batch mode but can't interact.
> 
> Ref bug#13697 and 8137, and commit 845fc5e5.

I agree.

bug#21833: 24.4; desktop-kill, which is interactive, is in kill-emacs-hook

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 528 bytes --]

On Fri, Nov 13, 2015 at 8:56 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> Why not decide that the sensible non-interactive behavior is to behave
> as if the answer is NO?  Can you think up a use cases where this would
> be terribly wrong?

If you have a complex setup, particularly involving frames (which are also
saved).

> FWIW, IME, whenever I see this question (interactively, of course),
> the correct answer is always NO.

In my case, the right answer is almost always YES (i.e,, I almost always
want to save the desktop).

[-- Attachment #2: Type: text/html, Size: 714 bytes --]

bug#21833: 24.4; desktop-kill, which is interactive, is in kill-emacs-hook

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 1116 bytes --]

On Fri, Nov 13, 2015 at 8:59 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> Then I guess you are saying that in the case of emacs-lock there's no
> similar bug?

No bug. I thought about it and decided that aborting in kill-emacs-hook was
the more reasonable behavior. After all, if you take the trouble to tell
Emacs that a buffer is precious enough not to want Emacs to exit while the
buffer is alive, you won't want to lose it by accident. If you're so hard
pressed to do M-x kill-emacs <RET>, you can precede that with M-x
emacs-lock-mode <RET> to toggle the protection off.

> I'll probably agree (I don't use that package), but why does it have
> to tell us that desktop.el should behave the same?  It doesn't have
> the same purpose, right?

No, and I'm not arguing that desktop.el should behave the same. Just that
the case isn't so clear-cut as the bug report seems to imply. In any case,
if the sensible thing is not to ask anything from kill-emacs-hook
(emacs-lock doesn't, BTW), then we have to provide an option so the user
can chose if they want their current desktop silently saved, or silently
discarded.

[-- Attachment #2: Type: text/html, Size: 1348 bytes --]

bug#21833: 24.4; desktop-kill, which is interactive, is in kill-emacs-hook

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 13 Nov 2015 10:30:41 +0100
> Cc: Glenn Morris <rgm@gnu.org>, 21833@debbugs.gnu.org, si@siancu.net
> 
> > Why not decide that the sensible non-interactive behavior is to behave
> > as if the answer is NO? Can you think up a use cases where this would
> > be terribly wrong?
> 
> If you have a complex setup, particularly involving frames (which are also
> saved). 

Sorry, I don't understand: what frames?  We are talking about
non-interactive situations, no?

> > FWIW, IME, whenever I see this question (interactively, of course),
> > the correct answer is always NO.
> 
> In my case, the right answer is almost always YES (i.e,, I almost always want
> to save the desktop).

Why?  In "emacs -Q", the desktop you have is ephemeral; overwriting
your last "normal" invocation's saved desktop runs a very real risk of
wiping out precious information.  The desktop file isn't versioned, so
you just lose it forever.  How can this ever be TRT?

bug#21833: 24.4; desktop-kill, which is interactive, is in kill-emacs-hook

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 13 Nov 2015 10:39:59 +0100
> Cc: Glenn Morris <rgm@gnu.org>, 21833@debbugs.gnu.org, si@siancu.net
> 
> > I'll probably agree (I don't use that package), but why does it have
> > to tell us that desktop.el should behave the same? It doesn't have
> > the same purpose, right?
> 
> No, and I'm not arguing that desktop.el should behave the same. Just that the
> case isn't so clear-cut as the bug report seems to imply. In any case, if the
> sensible thing is not to ask anything from kill-emacs-hook (emacs-lock doesn't,
> BTW), then we have to provide an option so the user can chose if they want
> their current desktop silently saved, or silently discarded.

I don't want to make a wider philosophical issue out of this bug
report.  the bug report is about desktop.el; let's solve that one use
case.  OK?

bug#21833: 24.4; desktop-kill, which is interactive, is in kill-emacs-hook

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 749 bytes --]

On Fri, Nov 13, 2015 at 11:01 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> Sorry, I don't understand: what frames?  We are talking about
> non-interactive situations, no?

There's nothing non-interactive in the OP use case. And desktop.el already
contains

  (unless noninteractive
    (add-hook 'kill-emacs-hook 'desktop-kill))

Try

  emacs -Q --batch --eval "(progn (desktop-save-mode 1) (kill-emacs))"

so what I'm discussing is whether desktop.el should try to protect the
desktop when the user, or some code, runs `kill-emacs'.

> Why?  In "emacs -Q", the desktop you have is ephemeral

Obviously, I'm not talking about the -Q case, and I don't thing the OP is,
either. That's just a recipe to show that kill-emacs asks an interactive
question.

[-- Attachment #2: Type: text/html, Size: 1103 bytes --]

bug#21833: 24.4; desktop-kill, which is interactive, is in kill-emacs-hook

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 375 bytes --]

On Fri, Nov 13, 2015 at 11:03 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> I don't want to make a wider philosophical issue out of this bug
> report.  the bug report is about desktop.el; let's solve that one use
> case.  OK?

What's philosophical in "we have to provide an option so the user can chose
if they want their current desktop silently saved, or silently discarded"?

[-- Attachment #2: Type: text/html, Size: 517 bytes --]

bug#21833: 24.4; desktop-kill, which is interactive, is in kill-emacs-hook

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 13 Nov 2015 11:14:57 +0100
> Cc: Glenn Morris <rgm@gnu.org>, 21833@debbugs.gnu.org, si@siancu.net
> 
> > In "emacs -Q", the desktop you have is ephemeral
> 
> Obviously, I'm not talking about the -Q case, and I don't thing the OP is,
> either. That's just a recipe to show that kill-emacs asks an interactive
> question.

That's not my interpretation of the original report.  It specifically
talks about "emacs -Q".

It also talks about the daemon.  If that's the problem, then I guess
desktop-kill could behave as if YES was answered when we run in daemon
mode and -Q was not given on the command line.  Would that make sense?

What other use cases are there where this issue could arise,
i.e. where the user couldn't answer the question?

bug#21833: 24.4; desktop-kill, which is interactive, is in kill-emacs-hook

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 13 Nov 2015 11:17:12 +0100
> Cc: Glenn Morris <rgm@gnu.org>, 21833@debbugs.gnu.org, si@siancu.net
> 
> > I don't want to make a wider philosophical issue out of this bug
> > report. the bug report is about desktop.el; let's solve that one use
> > case. OK?
> 
> What's philosophical in "we have to provide an option so the user can chose if
> they want their current desktop silently saved, or silently discarded"?

No, I was talking about bringing some other hooks into this
discussion.

bug#21833: 24.4; desktop-kill, which is interactive, is in kill-emacs-hook

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 784 bytes --]

On Fri, Nov 13, 2015 at 3:05 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> It also talks about the daemon.  If that's the problem, then I guess
> desktop-kill could behave as if YES was answered when we run in daemon
> mode and -Q was not given on the command line.  Would that make sense?

There are three "ask" cases in desktop-save.

   ask           -- always ask.
   ask-if-new    -- ask if no desktop file exists, otherwise just save.
   ask-if-exists -- ask if desktop file exists, otherwise don't save.

I'm not sure defaulting to YES in all cases is what makes more sense.

> What other use cases are there where this issue could arise,
> i.e. where the user couldn't answer the question?

Don't know. It is posible for an Emacs instance to have all frames in a
remote desktop?

[-- Attachment #2: Type: text/html, Size: 1078 bytes --]

bug#21833: 24.4; desktop-kill, which is interactive, is in kill-emacs-hook

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 360 bytes --]

On Fri, Nov 13, 2015 at 3:07 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> No, I was talking about bringing some other hooks into this
> discussion.

Oh, I didn't.

It was this comment by Glenn:

  There are several other instances of this form.
  Someone should check them all, and consider what TRT to do is when Emacs
  isn't in batch mode but can't interact.

[-- Attachment #2: Type: text/html, Size: 868 bytes --]

bug#21833: 24.4; desktop-kill, which is interactive, is in kill-emacs-hook

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 13 Nov 2015 15:35:22 +0100
> Cc: Glenn Morris <rgm@gnu.org>, 21833@debbugs.gnu.org, si@siancu.net
> 
> > It also talks about the daemon. If that's the problem, then I guess
> > desktop-kill could behave as if YES was answered when we run in daemon
> > mode and -Q was not given on the command line. Would that make sense?
> 
> There are three "ask" cases in desktop-save.
> 
> ask -- always ask.
> ask-if-new -- ask if no desktop file exists, otherwise just save.
> ask-if-exists -- ask if desktop file exists, otherwise don't save.
> 
> I'm not sure defaulting to YES in all cases is what makes more sense. 

If a daemon is exiting that was not invoked with -Q, yes, I think YES
will always make more sense than NO.  Can you tell why you aren't
sure?

> > What other use cases are there where this issue could arise,
> > i.e. where the user couldn't answer the question?
> 
> Don't know. It is posible for an Emacs instance to have all frames in a remote
> desktop?

I think only if invoked with -daemon.

bug#21833: 24.4; desktop-kill, which is interactive, is in kill-emacs-hook

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 507 bytes --]

On Fri, Nov 13, 2015 at 7:55 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> If a daemon is exiting that was not invoked with -Q, yes, I think YES
> will always make more sense than NO.  Can you tell why you aren't
> sure?

ask-if-new with default to YES is safe. In the other two cases, it is
impossible to decide a priori whether it is more important to protect an
existing .desktop file or the desktop configuration on the running instance.

But I'm OK with defaulting to YES and waiting for the bug reports.

[-- Attachment #2: Type: text/html, Size: 651 bytes --]

bug#21833: 24.4; desktop-kill, which is interactive, is in kill-emacs-hook

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sun, 15 Nov 2015 12:54:32 +0100
> Cc: Glenn Morris <rgm@gnu.org>, 21833@debbugs.gnu.org, si@siancu.net
> 
> ask-if-new with default to YES is safe. In the other two cases, it is
> impossible to decide a priori whether it is more important to protect an
> existing .desktop file or the desktop configuration on the running instance.
> 
> But I'm OK with defaulting to YES and waiting for the bug reports.

I agree.  Can you prepare a patch to that effect?

TIA