RE: put input focus on active minibuffer

RE: put input focus on active minibuffer

[Alexis]

Drew Adams <drew.adams@oracle.com> writes:

> I see.  You were saying how to do it on one's own, and not speaking to
> the OP's feature request for Emacs.  Sorry for not understanding that.

That's okay - sorry i wasn't clearer in the first place! Glad we were
able to sort it all out. :-)


Alexis.

put input focus on active minibuffer

[Katsumi Yamaoka]

Hi,

This is a feature request.
It would be useful if the input focus is always put on the
active minibuffer when a user clicks the mouse on any place of
the unselected Emacs frame.  For instance, when an Emacs frame
is not selected and it is waiting for a user for a yes-or-no-p
answer, a user will likely click a normal window.  In that case,
a user will have to do `C-x o' to go to the minibuffer now.  I
can guess everyone has experienced such a situation. :)

Thanks.

RE: put input focus on active minibuffer

[Drew Adams]

> This is a feature request.
> It would be useful if the input focus is always put on the
> active minibuffer when a user clicks the mouse on any place of
> the unselected Emacs frame.  For instance, when an Emacs frame
> is not selected and it is waiting for a user for a yes-or-no-p
> answer, a user will likely click a normal window.  In that case,
> a user will have to do `C-x o' to go to the minibuffer now.  I
> can guess everyone has experienced such a situation. :)

No, please do not do this.  A user should be able to select
different buffers and windows, including by clicking the mouse
or using keyboard keys, while the minibuffer is active.  A user
should be able to do all kinds of things while the minibuffer is
active - including come back to the minibuffer to continue
inputting text there etc.

Re: put input focus on active minibuffer

[Alexis]

Drew Adams <drew.adams@oracle.com> writes:

> No, please do not do this.  A user should be able to select 
> different buffers and windows, including by clicking the mouse 
> or using keyboard keys, while the minibuffer is active.  A user 
> should be able to do all kinds of things while the minibuffer is 
> active - including come back to the minibuffer to continue 
> inputting text there etc.

Agreed.

But, if using GNU Emacs 24.4 or later, perhaps make use of 
`focus-in-hook`? For example, something along the lines of:

#+BEGIN_SRC emacs-lisp

    (defun focus-to-active-minibuffer () 
      (if (minibuffer-window-active-p (minibuffer-window)) 
          (select-window (minibuffer-window)))) 
 
    (add-hook 'focus-in-hook #'focus-to-active-minibuffer) 

#+END_SRC


Alexis.

RE: put input focus on active minibuffer

[Drew Adams]

> > No, please do not do this.  A user should be able to select
> > different buffers and windows, including by clicking the mouse
> > or using keyboard keys, while the minibuffer is active.  A user
> > should be able to do all kinds of things while the minibuffer is
> > active - including come back to the minibuffer to continue
> > inputting text there etc.
> 
> Agreed.
> 
> But, if using GNU Emacs 24.4 or later, perhaps make use of
> `focus-in-hook`? For example, something along the lines of:
> 
>     (defun focus-to-active-minibuffer ()
>       (if (minibuffer-window-active-p (minibuffer-window))
>           (select-window (minibuffer-window))))
> 
>     (add-hook 'focus-in-hook #'focus-to-active-minibuffer)

If you do that then whenever a frame receives the focus so
will its (active) minibuffer window.  That precludes the user
interactions I described above, and about which you "Agreed".

A user needs to be able to interact with other windows directly,
whatever frame they are in.  This interaction needs to be able
to include inserting text etc. - actions that require that
window to have the focus.

Users need to be able to change the focus to anywhere they
like when the minibuffer is active.  Just because it is active
and the user will want to interact with it, does not mean that
the user should not be able to interact with other window as
well.

What you suggest could be useful for a particular command
that wants/needs, for some reason, to preclude the user from
focussing other windows while the minibuffer is active.  But
it is not applicable to the general case of using a minibuffer.

Re: put input focus on active minibuffer

[Alexis]

Drew Adams <drew.adams@oracle.com> writes:

>> > No, please do not do this.  A user should be able to select 
>> > different buffers and windows, including by clicking the 
>> > mouse or using keyboard keys, while the minibuffer is active. 
>> > A user should be able to do all kinds of things while the 
>> > minibuffer is active - including come back to the minibuffer 
>> > to continue inputting text there etc.
>> 
>> Agreed.
>> 
>> But, if using GNU Emacs 24.4 or later, perhaps make use of 
>> `focus-in-hook`? For example, something along the lines of:
>> 
>>     (defun focus-to-active-minibuffer () 
>>       (if (minibuffer-window-active-p (minibuffer-window)) 
>>           (select-window (minibuffer-window))))
>> 
>>     (add-hook 'focus-in-hook #'focus-to-active-minibuffer)
>
> If you do that then whenever a frame receives the focus so will 
> its (active) minibuffer window.  That precludes the user 
> interactions I described above, and about which you "Agreed".

Well, my suggestion was code to help the OP achieve the effect 
they want, without any other GNU Emacs users being affected. i'm 
sorry that my wording seems to have conveyed the impression that i 
was suggesting that my code be incorporated directly into GNU 
Emacs itself.


Alexis.

RE: put input focus on active minibuffer

[Drew Adams]

> >> But, if using GNU Emacs 24.4 or later, perhaps make use of
> >> `focus-in-hook`? For example, something along the lines of:
> >>
> >>     (defun focus-to-active-minibuffer ()
> >>       (if (minibuffer-window-active-p (minibuffer-window))
> >>           (select-window (minibuffer-window))))
> >>
> >>     (add-hook 'focus-in-hook #'focus-to-active-minibuffer)
> >
> > If you do that then whenever a frame receives the focus so will
> > its (active) minibuffer window.  That precludes the user
> > interactions I described above, and about which you "Agreed".
> 
> Well, my suggestion was code to help the OP achieve the effect
> they want, without any other GNU Emacs users being affected. i'm
> sorry that my wording seems to have conveyed the impression that i
> was suggesting that my code be incorporated directly into GNU
> Emacs itself.

I see.  You were saying how to do it on one's own, and not
speaking to the OP's feature request for Emacs.  Sorry for
not understanding that.

Re: put input focus on active minibuffer

[Yuri Khan]

On Sun, Feb 14, 2016 at 10:54 PM, Drew Adams <drew.adams@oracle.com> wrote:

> A user needs to be able to interact with other windows directly,
> whatever frame they are in.  This interaction needs to be able
> to include inserting text etc. - actions that require that
> window to have the focus.
>
> Users need to be able to change the focus to anywhere they
> like when the minibuffer is active.  Just because it is active
> and the user will want to interact with it, does not mean that
> the user should not be able to interact with other window as
> well.

I think there could be a useful middle ground, which is probably what
Katsumi meant.

A user clicks on an inactive frame which has an active minibuffer.
That frame is activated and the minibuffer focused. The idea is that
the user’s mental model for an inactive frame is that of an opaque
box.

A user clicks in an inactive window in the active frame which has an
active minibuffer. Now the window which was clicked is activated.

This way, to activate a window other than the minibuffer in an
inactive frame which has an active minibuffer, the user has to click
twice.

In my practice, this case is sufficiently rare that the utility of
Fitts’ law outweighs the cost of this additional click. Especially in
an overlapping windowing system where the minibuffer of an inactive
frame might not even be exposed, and therefore not directly clickable.

Re: put input focus on active minibuffer

[John Wiegley]

>>>>> Katsumi Yamaoka <yamaoka@jpl.org> writes:

> It would be useful if the input focus is always put on the
> active minibuffer when a user clicks the mouse on any place of
> the unselected Emacs frame.  For instance, when an Emacs frame
> is not selected and it is waiting for a user for a yes-or-no-p
> answer, a user will likely click a normal window.  In that case,
> a user will have to do `C-x o' to go to the minibuffer now.  I
> can guess everyone has experienced such a situation. :)

Hi Katsumi,

Since Emacs allows the use of other buffers while the minibuffer is waiting
for input, it's not uncommon to click on the window you want to interact with,
regardless of whether a question is being asked. So I don't think we can
change the default behavior to switch window focus based on such a question in
the minibuffer.

However, it does sound like an interesting configuration option, as I've
indeed been in that scenario many times before. My recommendation would be to
try out the code Alexis offered, and come back after some time has passed if
you feel the change improves your experience well enough that it should become
a standard option.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: put input focus on active minibuffer

[Katsumi Yamaoka]

On Fri, 19 Feb 2016 18:26:36 -0800, John Wiegley wrote:
> Since Emacs allows the use of other buffers while the minibuffer is waiting
> for input, it's not uncommon to click on the window you want to interact with,
> regardless of whether a question is being asked. So I don't think we can
> change the default behavior to switch window focus based on such a question in
> the minibuffer.

Agreed.  To tell the truth, I'm not necessarily sure if the feature
is really useful for me because I've never experienced it so far.

> However, it does sound like an interesting configuration option, as I've
> indeed been in that scenario many times before. My recommendation would be to
> try out the code Alexis offered, and come back after some time has passed if
> you feel the change improves your experience well enough that it should become
> a standard option.

Thanks for following it up, and sorry for my no response (as my
circuit design work is piled up these days).  I tried Alexis'
solution below but it changed nothing in at least Cygwin.

#+BEGIN_SRC emacs-lisp
(defun focus-to-active-minibuffer ()
  (if (minibuffer-window-active-p (minibuffer-window))
      (select-window (minibuffer-window))))

(add-hook 'focus-in-hook #'focus-to-active-minibuffer)
#+END_SRC

When I eval'd (read-file-name "What? ") in the *scratch* buffer,
selected another frame of the desktop, and clicked the *scratch*
window to re-select the Emacs frame in question, I could verify
`focus-to-active-minibuffer' was called and it selected the
minibuffer window (using edebug).  However, the cursor moved to
the *scratch* window after the hook function exited.  I guess
whether this does work might depend on the windowing system.  If
so, I can imagine it's not an easy matter to solve.

Anyway I think it's good if such an option were available.  It
has not to be turned on by default of course.

Regards,

Re: put input focus on active minibuffer

[Elias Mårtenson]

[-- Attachment #1: Type: text/plain, Size: 637 bytes --]

On 20 February 2016 at 10:26, John Wiegley <jwiegley@gmail.com> wrote:

> >>>>> Katsumi Yamaoka <yamaoka@jpl.org> writes:
>
> Since Emacs allows the use of other buffers while the minibuffer is waiting
> for input, it's not uncommon to click on the window you want to interact
> with,
> regardless of whether a question is being asked. So I don't think we can
> change the default behavior to switch window focus based on such a
> question in
> the minibuffer.


Just an idea:

What if the "focus to minibuffer on frame activation" is only enabled when
the focus was already in the minibuffer then the window lost focus?

Regards,
Elias

[-- Attachment #2: Type: text/html, Size: 1108 bytes --]