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

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

bug#46097: 27.1; Minibuffer may not be current when running minibuffer-e


From: martin rudalics
Subject: bug#46097: 27.1; Minibuffer may not be current when running minibuffer-exit-hook
Date: Thu, 28 Jan 2021 12:53:06 +0100

Resending since the debbugs address was dropped.  Please always keep
the debbugs address CC'd.  Thanks.

Yes, currently, adding a function to minibuffer-exit-hook locally is
unreliable because it isn't guaranteed that the function will be called.
I now believe this to be correct behaviour.
I used to think that this was an elegant way for a minibuffer to perform
cleanup on exit, because the hook function doesn't have to remove itself
from the hook.

The first problem I see here is that I have no clear idea what "buffer
local" means when we talk about the minibuffer.  The second problem is
that I have no idea which buffer is (or should be) current when
'minibuffer-exit-hook' is run: It could be the minibuffer just exited,
the next lower level minibuffer when exiting a recursive minibuffer or
some normal buffer when going back to the top level.

As long as these issues are not resolved (and clearly documented), it
hardly makes sense to guess what kind of effect one can achieve by
running a function on 'minibuffer-exit-hook'.

There are two minor inconveniences if a cleanup function is in (the
global value of) minibuffer-exit-hook. First, it has to remove itself
and second, it has to make sure it doesn't clean up too early after
possible inner recursive minibuffers, so something like

     (let ((depth (minibuffer-depth))
           h)
       (setq h (lambda ()
                 (when (= depth (minibuffer-depth))
                   (remove-hook 'minibuffer-exit-hook h)
                   (cleanup))))
       (add-hook 'minibuffer-exit-hook h))

My proposal is to use minibuffer's local value of change-major-mode-hook
instead:

     (add-hook 'change-major-mode-hook #'cleanup nil t)

This mostly has the same behaviour as the above, except that the cleanup
also happens when changing the major mode of the minibuffer, which may
perhaps even be desirable.

This sounds like capitulation.  And where would you run the 'add-hook' -
still in 'minibuffer-setup-hook' I suppose?  If we can't make these two
- 'minibuffer-setup-hook' and 'minibuffer-exit-hook' - symmetric and to
some extent dependable, we have a serious design flaw.

martin





reply via email to

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