* detached minibuffer woes
@ 2005-05-13 18:11 David Nelson
2005-05-20 21:28 ` Kevin Rodgers
0 siblings, 1 reply; 2+ messages in thread
From: David Nelson @ 2005-05-13 18:11 UTC (permalink / raw)
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.
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.
Ideally, there would be a variable that would cause the minibuffer to
be raised, but without stealing the focus.
Does anyone have any suggestions on this. I suspect the problems is
the lack of focus follows mouse in OS X's window manager.
Thanks ...
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: detached minibuffer woes
2005-05-13 18:11 detached minibuffer woes David Nelson
@ 2005-05-20 21:28 ` Kevin Rodgers
0 siblings, 0 replies; 2+ messages in thread
From: Kevin Rodgers @ 2005-05-20 21:28 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2005-05-20 21:28 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-05-13 18:11 detached minibuffer woes David Nelson
2005-05-20 21:28 ` Kevin Rodgers
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).