> On Wed, 23 Jul 2025 at 17:14, Chris Siebenmann <[email protected]>
> wrote:
> > I use GNU Emacs (and fvwm3), and unfortunately a small irritation with
> > this is that GNU Emacs has a quite irritating habit of de-iconifying
> > (and I think raising itself to the top of the window stack) any time it
> > finishes a long-running Lisp operation. If I start an operation that
> > takes a long time and iconify GNU Emacs, I want it to stay that way,
> > I don't want it to suddenly spring open like a giant modal popup.
[...]
> > This behavior appears to be burried deeply inside GNU Emacs so that I
> > can't modify it with the normal GNU Emacs ELisp tools. As a result, I'd
> > like to have fvwm just ignore any request from GNU Emacs to de-iconify
> > itself. Is this possible? There is the 'IgnoreRestack' style option,
>
> Sounds to me like this is due to "UrgencyFunc"? Is that possible?
> The default implementation
> will deiconify a window once something has happened. You can check
> this is the case with:
>
> DestroyFunc UrgencyFunc
>
> Let me know how you get on.
This doesn't appear to be GNU Emacs invoking UrgencyFunc; instead, Emacs
appears to be directly de-iconifying itself as part of internal
processing. For curious people who want to reproduce this in a standard
GNU Emacs environment, you can evaluate the following ELisp in the
'*scratch*' buffer and then iconify GNU Emacs:
(progn
(sleep-for 5)
(display-buffer "*scratch*"))
Five seconds or so later, GNU Emacs will spring back open.
I found a partial workaround for this inside GNU Emacs, although it
doesn't prevent all of the cases of GNU Emacs deciding to deiconify
itself when it's done some processing. That is setting:
(add-to-list 'display-buffer-alist '(t nil (inhibit-switch-frame . t)))
(A longer discussion of all of this is at
https://utcc.utoronto.ca/~cks/space/blog/programming/EmacsForcingNoDeiconification
for interested parties, if any. This modification stops the reproducer
above because it tells display-buffer to not do that.)
Since my ELisp hacking is only a partial workaround, I'd still be
interested if there's a way to get fvwm3 to stop allowing
program-directed deiconification with a style or something.
- cks
