Let me confirm one thing. The value doesn't affect the behavior with
respect to the mouse position on W32, either? I'm asking because I'm
thinking about setting its default to nil on Mac Carbon, because if
the value is t, C-x 5 o moves the mouse pointer to the upper-right
corner of the
Date: Sat, 16 Sep 2006 19:23:49 +0900 (JST)
From: [EMAIL PROTECTED]
Cc: Eli Zaretskii [EMAIL PROTECTED], emacs-pretest-bug@gnu.org,
Drew Adams [EMAIL PROTECTED]
Thanks. I think users don't expect that the mouse pointer is
moved with C-x 5 o on W32 and Mac, in which click-to-focus is
Thanks. I think users don't expect that the mouse pointer is
moved with C-x 5 o on W32 and Mac, in which click-to-focus is
the default. I'll set focus-follows-mouse to nil on these
platforms by default if there's no objection.
If you do that, users will need to do more than they do now to
Date: Sat, 16 Sep 2006 20:52:45 +0900 (JST)
From: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org, [EMAIL PROTECTED]
So, select-frame-set-input-focus, which is called at end of
other-frame, fails to set input focus to the specified frame on
W32?
No, it doesn't fail, not
Sorry, I'm confused now: could you please reiterate what was the
reason for the change you suggested? If the focus is moved to the
specified frame, why does it make sense to leave the mouse pointer on
the previous frame?
It is not necessary for the mouse pointer to point to the
previous
Date: Sat, 16 Sep 2006 22:11:27 +0900 (JST)
From: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org, [EMAIL PROTECTED]
Sorry, I'm confused now: could you please reiterate what was the
reason for the change you suggested? If the focus is moved to the
specified frame,
It is not necessary for the mouse pointer to point to the
previous frame before C-x 5 o in the click-to-mouse setting.
The typical case is that it points to the Taskbar on W32 or the
Dock on Mac.
YAMAMOTO Mitsuharu
[EMAIL
Moreover, moving the mouse pointer is not the main objective of
select-frame-set-input-focus or other-frame
Neither it's its objective to leave the pointer where it were.
Are you joking? What function would have its objective to leave
the pointer where it was?
Please read the previous
Eli Zaretskii [EMAIL PROTECTED] writes:
Okay, but I think what Emacs does now is better. Do we need to follow
bad example of Alt-TAB?
I have to disagree here. If the user is using the keyboard to switch
frames, then they probably want the pointer to stay out of the way,
not move to the frame
On Sat, 15 Jul 2006 11:47:15 +0300, Eli Zaretskii [EMAIL PROTECTED]
said:
The default value should still reflect what's appropriate for the platform,
even if for most purposes it's ignored by the OS. The OS might not DTRT,
but
the behavior of Emacs code depends on the value of Emacs
YAMAMOTO Mitsuharu wrote:
Let me confirm one thing. The value doesn't affect the behavior with
respect to the mouse position on W32, either? I'm asking because I'm
thinking about setting its default to nil on Mac Carbon, because if
the value is t, C-x 5 o moves the mouse pointer to the
From: Drew Adams [EMAIL PROTECTED]
Date: Sat, 15 Jul 2006 09:00:58 -0700
I did try it, with both nil and t as values of focus-follows-mouse,
and I don't see _any_ change in behavior whatsoever.
You're right. I didn't test it with different values of the option.
Thanks, I
Thanks, I documented that this variable has no effect on Windows.
Thx.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
From: Drew Adams [EMAIL PROTECTED]
Date: Fri, 14 Jul 2006 12:57:32 -0700
Anyway, I cannot see any difference in behavior of, say, C-x 5 o
(which calls select-frame-set-input-focus, which Drew cited) that
depends on the value of this variable. Can someone post a recipe to
From: Drew Adams [EMAIL PROTECTED]
Date: Fri, 14 Jul 2006 12:57:32 -0700
Anyway, I cannot see any difference in behavior of, say, C-x 5 o
(which calls select-frame-set-input-focus, which Drew cited) that
depends on the value of this variable. Can someone post a recipe to
(defun select-frame-set-input-focus (frame)
Select FRAME, raise it, and set input focus, if possible.
(select-frame frame)
(raise-frame frame)
;; Ensure, if possible, that frame gets input focus.
(cond ((eq window-system 'x) (x-focus-frame frame))
((eq
Anyway, I cannot see any difference in behavior of, say, C-x 5 o
Documenting that would seem to be wrong, as the example I
sent shows. In that example, if the value is nil, then the mouse
position does not get set; if non-nil, it gets set.
Is this the example you are
There are window managers that does not allow focus changes outside the
window
that has the mouse in it, if focus follows mouse. Metacity and sawfish
calls this mode focus-follows-mouse-strict. In that case, the code
above moves the mouse to the new window so it gets the focus. It is not
From: Drew Adams [EMAIL PROTECTED]
Date: Sat, 15 Jul 2006 09:00:58 -0700
this doesn't
happen on Windows, at least not for me, and the documentation of the
Windows API call invoked by w32-focus-frame seems to confirm that.
Dunno about the latter part. Do you mean just because
Date: Sat, 15 Jul 2006 16:00:03 +0200
From: martin rudalics [EMAIL PROTECTED]
CC: Eli Zaretskii [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
I think Windows never had a thing like focus-follows-mouse-strict or
focus-under-mouse. Windows' official non-click philosophy is to
change focus
... you have to explicitly click on the desktop in order
to give it focus.
That's the default, yes. But one can tweak the Registry to force
Windows behave more like X, in that just entering a window with the
mouse gives it focus. (I do this on any Windows machine I need to
work on,
Why is focus-follows-mouse t by default on MS Windows? The
doc string says:
Non-nil if window system changes focus when you move the mouse.
You should set this variable to tell Emacs how your window manager
handles focus, since there is no way in general for Emacs to
Cc: Drew Adams [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
From: Stefan Monnier [EMAIL PROTECTED]
Date: Fri, 14 Jul 2006 11:09:00 -0400
Eli: this variable is not meant to control the window manager, but to inform
Emacs of what is the window manager's behavior.
Then someone will have to
Cc: Drew Adams [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
From: Stefan Monnier [EMAIL PROTECTED]
Date: Fri, 14 Jul 2006 11:09:00 -0400
Eli: this variable is not meant to control the window manager, but to inform
Emacs of what is the window manager's behavior.
Then someone will have to
Cc: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
From: Stefan Monnier [EMAIL PROTECTED]
Date: Fri, 14 Jul 2006 14:17:36 -0400
But you've explicitly changed the Windows default, so it's probably OK to
require you change the Emacs var as well. Maybe the setting can even be
extracted from
Date: Fri, 14 Jul 2006 22:48:27 +0300
From: Eli Zaretskii [EMAIL PROTECTED]
Cc: emacs-pretest-bug@gnu.org, [EMAIL PROTECTED]
The problem is, the name of the registry entry that controls this
changes with every version of Emacs.
^
I meant Windows, of
But you've explicitly changed the Windows default, so it's
probably OK to require you change the Emacs var as well.
Maybe the setting can even be extracted from the registry?
The problem is, the name of the registry entry that controls this
changes with every version of
Why is focus-follows-mouse t by default on MS Windows? The doc string says:
Non-nil if window system changes focus when you move the mouse.
You should set this variable to tell Emacs how your window manager
handles focus, since there is no way in general for Emacs to find out
automatically.
From: Drew Adams [EMAIL PROTECTED]
Date: Tue, 11 Jul 2006 09:17:41 -0700
Why is focus-follows-mouse t by default on MS Windows? The doc string says:
Non-nil if window system changes focus when you move the mouse.
You should set this variable to tell Emacs how your window manager
handles
29 matches
Mail list logo
