bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#28542: Temporary failure in name resolution while quitting emacs


From: Lars Ingebrigtsen
Subject: bug#28542: Temporary failure in name resolution while quitting emacs
Date: Mon, 30 Nov 2020 11:53:24 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Baylis Shanks <bshanks3@hotmail.com> writes:

> I had an http address open in a buffer (i think i closed that buffer),
> and then i disconnected from the internet and then attempted to quit
> emacs. Emacs would not quit; when i attempted to quit it, a message
> involving 'open-network-stream' and 'temporary failure in name
> resolution' would be displayed in *messages* and then nothing would
> happen.
>
> Manually opening an elisp buffer and using setq to remove
> save-place-kill-emacs-hook from kill-emacs-hook solved the problem.

(This bug report unfortunately got no response at the time.)

I'm guessing you don't have a backtrace here to let us see what the code
in question was after all this time?

> 2) more importantly, if there is an error in something called from
> kill-emacs-hook, emacs should not just return to normal functioning
> (without quitting), but rather should give the user a choice of
> whether to continue to quit or not (if continue to quit is chosen, the
> remaining items in kill-emacs-hook should be called). It's really
> frustrating to a user when the user cannot figure out how to quit a
> program.

I agree.  To reproduce:

(push (lambda () (error "this is an error")) kill-emacs-hook)
`C-x C-c'

Result: Just an error message, and you can't kill Emacs.  I think it
should catch the error and ask whether to continue anyway.  Opinions?

The flow control here is a bit odd, though.  `save-buffers-kill-emacs'
calls Fkill_emacs, which starts:

DEFUN ("kill-emacs", Fkill_emacs, Skill_emacs, 0, 1, "P",
[...]
  /* Fsignal calls emacs_abort () if it sees that waiting_for_input is
     set.  */
  waiting_for_input = 0;
  if (noninteractive)
    safe_run_hooks (Qkill_emacs_hook);
  else
    run_hook (Qkill_emacs_hook);

Is this bit done from the C level because of that waiting_for_input
setting?  And...  I don't understand the comment -- the `error' (which
calls signal?) doesn't abort Emacs?  Anybody?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





reply via email to

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