[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: |
Wed, 02 Dec 2020 10:47:31 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Eli Zaretskii <eliz@gnu.org> writes:
> The ELisp manual says ab out kill-emacs-hook:
>
> 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 don't think we can safely ask whether to continue.
I don't quite interpret it that way -- this only says that if your
intention is to communicate with the user, then use
`kill-emacs-query-functions'.
The current situation is that if you have an error in `kill-emacs-hook'
(and you're running an interactive Emacs), then you can't kill Emacs at
all. Adding a query to the user about what to do is an improvement, and
won't regress anything.
> We could either use safe_run_hooks, as we do in the noninteractive
> case (thus silently ignoring errors in this hook even if we do have a
> means to communicate with the user), or maybe move the offending
> function to kill-emacs-query-functions. Or try a more limited
> solution of ensuring this particular function doesn't signal an error,
> or catches it and returns.
I'm a bit leery at doing anything automatically (either ignoring the
error or re-running it from a different context). The hook may be, for
instance, writing stuff to a data file and then clearing out some
structures, and re-writing the stuff may clear the data, for instance.
Only the user should be making a judgement call in the error situation
here.
>> 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?
>
> I think the comment has this exact scenario in mind: if we don't make
> sure waiting_for_input is zero, and the hook just happens to signal an
> error, Emacs will dump core.
Oh, I interpreted it the opposite way -- that "waiting_for_input = 0" is
setting it. To zero. But it means "isn't cleared"?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
- bug#28542: Temporary failure in name resolution while quitting emacs,
Lars Ingebrigtsen <=
- bug#28542: Temporary failure in name resolution while quitting emacs, Eli Zaretskii, 2020/12/02
- bug#28542: Temporary failure in name resolution while quitting emacs, Lars Ingebrigtsen, 2020/12/03
- bug#28542: Temporary failure in name resolution while quitting emacs, Eli Zaretskii, 2020/12/03
- bug#28542: Temporary failure in name resolution while quitting emacs, Lars Ingebrigtsen, 2020/12/04
- bug#28542: Temporary failure in name resolution while quitting emacs, Robert Pluim, 2020/12/04
- bug#28542: Temporary failure in name resolution while quitting emacs, Glenn Morris, 2020/12/04
- bug#28542: Temporary failure in name resolution while quitting emacs, Lars Ingebrigtsen, 2020/12/06
- bug#28542: Temporary failure in name resolution while quitting emacs, Eli Zaretskii, 2020/12/04
- bug#28542: Temporary failure in name resolution while quitting emacs, Lars Ingebrigtsen, 2020/12/06
- bug#28542: Temporary failure in name resolution while quitting emacs, Eli Zaretskii, 2020/12/06