Re: detached minibuffer woes

[Kevin Rodgers]

David Nelson wrote:
> I'm using Carbon Emacs (emacs for OS X) which is based on GNU Emacs
> 22.0.50.2. OS X has a "click to focus" window manager.
>
> I'm trying to set up a detached or floating minibuffer arrangement.
> I've nearly got this working the way I would like, but I've hit a  wall.
> As currently configured, I'm using minibuffer-setup-hook to  raise the
> frame containing the minibuffer. I use minibuffer-exit-hook  to set the
> focus back to the frame I was working in when the  minibuffer is done.
>
> This works great except that if the minibuffer is showing status
> information, it does not get raised.

That's because messages are output to the echo area, which is
conceptually distinct from the minibuffer.  They may share the same
screen real estate, but calling message does not activate the
minibuffer, which would invoke minibuffer-setup-hook.

> I tried using minibuffer-auto-raise, but that's too aggressive. It
> takes the focus away from the window I'm working on for everything
> concerning the minibuffer. For example, if I do something involving
> setting the mark, the minibuffer displays a message about that, but  it
> also takes the focus away from the frame I'm editing in.

Can you advise the message function, to save and reset the focus just
like you did in minibuffer-setup-hook/minibuffer-exit-hook?

> Ideally, there would be a variable that would cause the minibuffer to
> be raised, but without stealing the focus.

Yes, Emacs seems to conflate input focus and frame stacking, especially
on non-X platforms.

> Does anyone have any suggestions on this. I suspect the problems is  the
> lack of focus follows mouse in OS X's window manager.

I'm curious whether follow-mouse.el (which implements
focus-follows-mouse within Emacs) works for you:
http://www.emacswiki.org/elisp/follow-mouse.el

--
Kevin Rodgers