Hi Chris,
I don't have an FVWM3 solution. Sorry if this is not relevant, but have
you considered running the program in in a non-windowed version of emacs
(emacs -nw) or running your elisp program in "batch" mode?
The expression below:
(progn (sleep-for 10) 't)
does not cause emacs to try to deiconify when run in *scratch* with
either eval-last-sexp or eval-print-last-sexp. Is it possible that there
is something in the code that you are running that is explicitly calling
a function to display a buffer/frame? Another tack might be to try to
determine why the code that you are running is causing a frame to
display when other elisp code does not.
On the other hand, if expression above does indeed cause your emacs to
deiconify, then maybe there is something in my FVWM3 or emacs config
that is related to preventing emacs frame deiconification.
Cheers,
Ron
==
On 8/19/25 13:48, Thomas Adam wrote:
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.
Chris,
Apologies for the slow-reply, it seems this went to my spam folder for
some reason.
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.
Kindly,
Thomas
--
-----BEGIN PGP SIGNED MESSAGE-----
R3V2ZiB6cmZmbnRyIHZmYSdnIGVybnl5bCBmdnRhcnEuIFYgd2hmZyBoZnIgZ3VyIGZnZXZhdApu
b2JpciAgZ2IgbmlidnEgdW5pdmF0IHl2YXhmIHl2eHI6CgogICAgICAgIHVnZ2M6Ly9qamouc2Ji
LnBiei8KCnpuYXR5cnEgb2wgQnNzdnByIDM2NS4KCg==
-----END PGP SIGNATURE-----
