eldoc vs minibuffer-auto-raise

eldoc vs minibuffer-auto-raise

[martin rudalics]

Since I'm not using minibuffer-only frames I'm asking here how the
following is supposed to behave: With emacs -Q I load a file with the
two lines

(setq initial-frame-alist '((minibuffer . nil)))
(setq minibuffer-auto-raise t)

and then in *scratch* I start typing something like

(setq

A short pause here switches focus to the minibuffer frame and typing
the subsequent space character gets me

SPC is undefined

Obviously, eldoc intervenes here since doing the same with Emacs 24
proceeds without problems.

I'd like to know whether people using separate minibuffer frames see
this problem, circumvent it by not using 'minibuffer-auto-raise' or
disabling 'eldoc-mode' or whatever exists to handle this behavior in a
reasonable way.  If there was a previous discussion about this, please
point me to it.

Thanks, martin

RE: eldoc vs minibuffer-auto-raise

[Drew Adams]

> (setq minibuffer-auto-raise t)
> and then in *scratch* I start typing something like
> (setq
> A short pause here switches focus to the minibuffer frame and typing
> the subsequent space character gets me
> 
> SPC is undefined
> 
> Obviously, eldoc intervenes here since doing the same with Emacs 24
> proceeds without problems.
> 
> I'd like to know whether people using separate minibuffer frames see
> this problem, circumvent it by not using 'minibuffer-auto-raise' or
> disabling 'eldoc-mode' or whatever exists to handle this behavior in a
> reasonable way.  If there was a previous discussion about this, please
> point me to it.

I mention this because you asked about uses of standalone
minibuffer frames.  But I'm pretty sure it won't help you.
I didn't try from `emacs -Q', and my setup is far from
`emacs -Q'.

I use a standalone minibuffer frame.  I have eldoc turned
on and `minibuffer-auto-raise' = t.

I don't see (e.g. with Emacs 26) what you describe.  In my
case focus does not switch to the minibuffer frame.

I'm using MS Windows.  Perhaps the window mgr is involved
here, switching the focus to the minibuffer frame in your
case?

Re: eldoc vs minibuffer-auto-raise

[martin rudalics]

 > I'm using MS Windows.  Perhaps the window mgr is involved
 > here, switching the focus to the minibuffer frame in your
 > case?

No.  I suppose you have set 'w32-grab-focus-on-raise' to nil so you
won't see this behavior.

martin

Re: eldoc vs minibuffer-auto-raise

[Eli Zaretskii]

> Date: Sat, 19 Jan 2019 19:49:07 +0100
> From: martin rudalics <rudalics@gmx.at>
> 
>  > I'm using MS Windows.  Perhaps the window mgr is involved
>  > here, switching the focus to the minibuffer frame in your
>  > case?
> 
> No.  I suppose you have set 'w32-grab-focus-on-raise' to nil so you
> won't see this behavior.

FWIW, I didn't customize 'w32-grab-focus-on-raise', and I, like Drew,
don't see the problem you describe.

RE: eldoc vs minibuffer-auto-raise

[Drew Adams]

>  > I'm using MS Windows.  Perhaps the window mgr is involved
>  > here, switching the focus to the minibuffer frame in your
>  > case?
> 
> No.  I suppose you have set 'w32-grab-focus-on-raise' to nil so you
> won't see this behavior.

Yes, it's nil.  (Not that I even remembered what
that variable is or does, or when I set it to nil.)

However, I see the same behavior even if I set the
var to `t'.  In my case, no doubt due to something
else in my setup, the focus stays where I left it,
in the *scratch* frame.  Eldoc puts its msgs in the
minibuffer frame (in the echo area, presumably), and
focus stays put, in *scratch*.

However2: With the variable = t things are really
annoying outside of Emacs!

E.g., while typing this mail in Outlook (not Emacs),
Eldoc (?) keeps periodically sending the window-mgr
focus to the Emacs *scratch* frame (not to the
minibuffer frame - again, no doubt due to my setup),
so text I try to type into Outlook ends up in
*scratch*.  That's creepy weird.

I'm not familiar with that variable, and I don't
really make much, if any, real use of Eldoc, but
if other users also find Eldoc periodically stealing
focus from other window-mgr windows and redirecting
it to some Emacs frame I'd think that would be quite
annoying.  (Has anyone reported that?)

Good thing I have it set to nil, I guess.

Re: eldoc vs minibuffer-auto-raise

[martin rudalics]

 > FWIW, I didn't customize 'w32-grab-focus-on-raise', and I, like Drew,
 > don't see the problem you describe.

Then I'm clueless.

martin

Re: eldoc vs minibuffer-auto-raise

[martin rudalics]

 >> No.  I suppose you have set 'w32-grab-focus-on-raise' to nil so you
 >> won't see this behavior.
 >
 > Yes, it's nil.  (Not that I even remembered what
 > that variable is or does, or when I set it to nil.)
 >
 > However, I see the same behavior even if I set the
 > var to `t'.

Eli noted the same.  Strange.

 > In my case, no doubt due to something
 > else in my setup, the focus stays where I left it,
 > in the *scratch* frame.  Eldoc puts its msgs in the
 > minibuffer frame (in the echo area, presumably), and
 > focus stays put, in *scratch*.

This sounds a bit like focus redirection.  I'm not so familiar with
that.

 > However2: With the variable = t things are really
 > annoying outside of Emacs!
 >
 > E.g., while typing this mail in Outlook (not Emacs),
 > Eldoc (?) keeps periodically sending the window-mgr
 > focus to the Emacs *scratch* frame (not to the
 > minibuffer frame - again, no doubt due to my setup),
 > so text I try to type into Outlook ends up in
 > *scratch*.  That's creepy weird.

This must be related to your setup, some timer maybe.

 > I'm not familiar with that variable, and I don't
 > really make much, if any, real use of Eldoc, but
 > if other users also find Eldoc periodically stealing
 > focus from other window-mgr windows and redirecting
 > it to some Emacs frame I'd think that would be quite
 > annoying.  (Has anyone reported that?)
 >
 > Good thing I have it set to nil, I guess.

Maybe.  I cannot see any of the behavior you describe here.

martin