Can Emacs help here (running on Linux, display on Windows)?

Can Emacs help here (running on Linux, display on Windows)?

[Skip Montanaro]

One thing I liked about the Mac was that click-to-focus meant exactly that.
If you hovered your mouse over a window which didn't have keyboard focus
and clicked, it changed keyboard focus, full stop. Said focus-changing
click was not also sent to the application. On Linux systems there is a
wide enough variety of window managers and one can either switch from
click-to-focus to focus-follows-mouse, or find a window manager which "does
the right thing."

Windows, not so much. I'd never used Windows until landing at my latest
job. Despite the fact that they employed me to write software for and on
Linux, they placed this Windows computer on my desk. Consequently, I
generally run with a bunch of PuTTY windows connected to Linux servers.
From one of those windows I fire up my beloved Emacs with DISPLAY set back
to the Windows machine. (The Windows desktop machine runs something called
VcXsrv as an X11 server.)

I'm now faced with a small problem. Click-to-focus is the rule, but stupid,
stupid Windows also insists on passing the same click used to change focus
to the application itself. Maybe VcXsrv has some setting I've not
discovered (I can't even find the damn thing on the computer.) Is there
some way to make it stop? Can Emacs come to the rescue and somehow ignore
that initial, point-changing click?

Thx,

Skip Montanaro

Re: Can Emacs help here (running on Linux, display on Windows)?

[Eli Zaretskii]

> From: Skip Montanaro <skip.montanaro@gmail.com>
> Date: Fri, 4 Aug 2017 15:26:21 -0500
> 
> I'm now faced with a small problem. Click-to-focus is the rule, but stupid,
> stupid Windows also insists on passing the same click used to change focus
> to the application itself. Maybe VcXsrv has some setting I've not
> discovered (I can't even find the damn thing on the computer.) Is there
> some way to make it stop? Can Emacs come to the rescue and somehow ignore
> that initial, point-changing click?

What do you mean by "ignore"?  What does Emacs do upon that click that
you'd like to avoid?  (I never used a Mac, and hope I never will, so I
have no idea what does "change keyboard focus, full stop" really
mean, on a GUI system where the window that has focus receives a flood
of window-system events right away.)

In any case, you can have focus-follows-mouse on Windows as well,
although it's a bit more tricky than on X.  I always set up my Windows
machines to do that, because having to click a window (and as result
raise it to the top-most position in z-order) to have focus in it
drives me mad.  However, given that I don't understand what part of a
click you'd like Emacs to ignore, I cannot be sure that even having
focus-follows-mouse on Windows will solve your problem.

Re: Can Emacs help here (running on Linux, display on Windows)?

[ken]

On 08/05/2017 02:38 AM, Eli Zaretskii wrote:
> From: Skip Montanaro<skip.montanaro@gmail.com>
> Date: Fri, 4 Aug 2017 15:26:21 -0500
>
> I'm now faced with a small problem. Click-to-focus is the rule, but stupid,
> stupid Windows also insists on passing the same click used to change focus
> to the application itself. Maybe VcXsrv has some setting I've not
> discovered (I can't even find the damn thing on the computer.) Is there
> some way to make it stop? Can Emacs come to the rescue and somehow ignore
> that initial, point-changing click?

How about if you click on the window's border?

Re: Can Emacs help here (running on Linux, display on Windows)?

[Bob Proulx]

Eli Zaretskii wrote:
> Skip Montanaro wrote:
> > I'm now faced with a small problem. Click-to-focus is the rule, but stupid,
> > stupid Windows also insists on passing the same click used to change focus
> > to the application itself. Maybe VcXsrv has some setting I've not
> > discovered (I can't even find the damn thing on the computer.) Is there
> > some way to make it stop? Can Emacs come to the rescue and somehow ignore
> > that initial, point-changing click?
> 
> What do you mean by "ignore"?  What does Emacs do upon that click that
> you'd like to avoid?  (I never used a Mac, and hope I never will, so I
> have no idea what does "change keyboard focus, full stop" really
> mean, on a GUI system where the window that has focus receives a flood
> of window-system events right away.)

When gui emacs receives the mouse click it moves the point to that
location from wherever it was before.  The point is moved.  You might
not want to move the point because it was where it needed to be for
the next edit.  But clicking on the window to raise it will also move
the point.

This is one of the reasons that I often use emacs inside of an XTerm
solely because then clicking on the window does not generate a mouse
event inside the terminal.  And also why mouseless window managers are
useful.  Moving focus and raising windows without generating a click
event and moving the point.

Skip, I think your only option is to click on the title, frame, or
border.  That should raise the window without sending an event to
emacs.  Or alternatively switching to using a emacs inside of a
terminal window.  Then clicking on the terminal will raise the
terminal without sending a mouse event to emacs.

Bob

Re: Can Emacs help here (running on Linux, display on Windows)?

[Skip Montanaro]

> When gui emacs receives the mouse click it moves the point to that
> location from wherever it was before.  The point is moved.  You might
> not want to move the point because it was where it needed to be for
> the next edit.  But clicking on the window to raise it will also move
> the point.
...
> Skip, I think your only option is to click on the title, frame, or
> border.  That should raise the window without sending an event to
> emacs.  Or alternatively switching to using a emacs inside of a
> terminal window.  Then clicking on the terminal will raise the
> terminal without sending a mouse event to emacs.

Thanks. I was hoping there was some magic little ELisp function I
could write which was activated when Emacs lost focus. It would gobble
up mouse events until the click came for the focus, eat it, then
return, leaving the normal event processing to take over.

The only reason it occurred to me that something like this might be
possible is that it appears Excel does exactly this. If you have a
cell highlighted, when focus disappears, the highlighting disappears
as well (which I find a bit annoying), then returns to that same cell
when you click the worksheet to give it focus. The highlighting
doesn't move to whatever cell the pointer happened to be over. Of the
few other Windows apps I've used, I d on't recall them having this
(nice) behavior.

Not a huge deal. I'll try and get into the habit of clicking the title
bar. I notice that as I've aged (I'm 63 now, started with Gosling
Emacs on VMS at 28), my accuracy with the mouse has degraded a bit.
Certainly some of it is related to the age effect, though some of it
might be that the setups of my various computing environments are
suboptimal.

Skip Montanaro

Re: Can Emacs help here (running on Linux, display on Windows)?

[Stefan Monnier]

> generally run with a bunch of PuTTY windows connected to Linux servers.

[ I assume you mean GNU/Linux servers, since Linux itself doesn't provide
  much in terms of usable server and the other common OS built on top of
  Linux (aka Android) is pretty flimsy when it comes to
  server functionality.  ]

> I'm now faced with a small problem. Click-to-focus is the rule, but stupid,
> stupid Windows also insists on passing the same click used to change focus
> to the application itself. Maybe VcXsrv has some setting I've not
> discovered (I can't even find the damn thing on the computer.)  Is there
> some way to make it stop?  Can Emacs come to the rescue and somehow ignore
> that initial, point-changing click?

In theory you could try playing with `focus-in-hook' and
`focus-out-hook' to keep track of whether we have focus and ignore
events received while we don't have focus (and/or the first event
received after getting focus if it's a click).

But this assumes your Emacs is running a GUI session, whereas you
mention PuTTY above, in which case Emacs has receives no information
whatsoever about GUI events such as focus change: you'd have to tweak
PuTTY to do that instead.


        Stefan

Re: Can Emacs help here (running on Linux, display on Windows)?

[Yuri Khan]

On Sat, Aug 5, 2017 at 3:26 AM, Skip Montanaro <skip.montanaro@gmail.com> wrote:

> I'm now faced with a small problem. Click-to-focus is the rule, but stupid,
> stupid Windows also insists on passing the same click used to change focus
> to the application itself. Maybe VcXsrv has some setting I've not
> discovered (I can't even find the damn thing on the computer.) Is there
> some way to make it stop? Can Emacs come to the rescue and somehow ignore
> that initial, point-changing click?

Has it occured to you that you’re trying to solve a policy problem
with technical means?

Talk to your superior. Ask if you could set up your workstation for
your workflow.

Re: Can Emacs help here (running on Linux, display on Windows)?

[Bob Proulx]

Skip Montanaro wrote:
> Thanks. I was hoping there was some magic little ELisp function I
> could write which was activated when Emacs lost focus. It would gobble
> up mouse events until the click came for the focus, eat it, then
> return, leaving the normal event processing to take over.

Stefan Monnier suggested some focus hooks that could perhaps be used
to program exactly what you suggest.  But it would need some
programming.  Sounds possible though.

> Not a huge deal. I'll try and get into the habit of clicking the title
> bar. I notice that as I've aged (I'm 63 now, started with Gosling
> Emacs on VMS at 28), my accuracy with the mouse has degraded a bit.
> Certainly some of it is related to the age effect, though some of it
> might be that the setups of my various computing environments are
> suboptimal.

I had suggested clicking on the title, border, frame, but you might
also try Alt-TAB switching.  And Shift-Alt-TAB for reversing the
order.  Left thumb holding down on the Alt.  Left finger tapping on
the TAB key.  If you go past then the right pinky on the shift
reverses the direction through the list.  It isn't the best interface,
especially when there are many windows active, but it is one that most
window managers implement in some way or another and is therefore
fairly universal.  And no spurious mouse events to move the point.

I think borders have gotten smaller since I have gotten older.
Certainly the small fonts have gotten smaller. :-)

Bob

Re: Can Emacs help here (running on Linux, display on Windows)?

[Skip Montanaro]

Has it occured to you that you’re trying to solve a policy problem
with technical means?

Talk to your superior. Ask if you could set up your workstation for
your workflow.


Yes, BTDT. Good suggestion though.

I hold out hope that someday the company will allow me to have a *nix
desktop with a Windows VM for those few Win apps my work requires.

Skip

Re: Can Emacs help here (running on Linux, display on Windows)?

[Óscar Fuentes]

Bob Proulx <bob@proulx.com> writes:

> I had suggested clicking on the title, border, frame, but you might
> also try Alt-TAB switching.  And Shift-Alt-TAB for reversing the
> order.

Clicking on the task bar entry that corresponds to Emacs also works.

But using the mouse for switching focus is inefficient and, most likely,
unergonomic.

There are little programs out there that allow to define global shorcuts
associated to actions. IIRC I have some of my Windows machines
configured with one such tool that allows me to use the same keyboard
shorcuts that I use on my GNU/Linux workstations for switching focus to
Emacs, Firefox, etc.

Re: Can Emacs help here (running on Linux, display on Windows)?

[Skip Montanaro]

In theory you could try playing with `focus-in-hook' and
`focus-out-hook' ...


Thanks might take a look at that possibility.

Skip

Re: Can Emacs help here (running on Linux, display on Windows)?

[Emanuel Berg]

Yuri Khan wrote:

> Has it occured to you that you’re trying to
> solve a policy problem with technical means?

Yes, and that never works, or at least it never
worked for me. But the worst part of it is that
when it fails, everyone will blame everyone and
everyone will feel entitled to do so, as no one
actually solved the problem to his/her liking.

> Talk to your superior. Ask if you could set up
> your workstation for your workflow.

Better just do it. It is easier to get
permission for something after you do it. It is
like in Denmark, whenever you do something
illegal, afterwards, you receive a permission
to do it.

-- 
underground experts united
http://user.it.uu.se/~embe8573