GNU bug report logs - #3931
23.0.96; doc of select-frame-set-input-focus and select-frame

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 3931 in the body.
You can then email your comments to 3931 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <emacs-pretest-bug <at> gnu.org>
Subject: 23.0.96; doc of select-frame-set-input-focus and select-frame
Date: Sun, 26 Jul 2009 09:44:13 -0700

Doc string of `select-frame':
 
"If you are using a window system, the previously selected frame may
be restored as the selected frame after return to the command loop..."
 
That's grammatically incorrect - "return" should presumably be
"returning" (depending on what is intended by the sentence).
 
In any case, this paragraph of the description is not very clear.
 

Doc string of `select-frame-set-input-focus':
 
"If `mouse-autoselect-window' is non-nil, also move mouse cursor to
FRAME's selected window.  Otherwise, if `focus-follows-mouse' is
non-nil, move mouse cursor to FRAME."
 
"Mouse cursor" is incorrect; "pointer" is correct (or "mouse pointer",
but, strictly speaking, "mouse" is redundant for the pointer).
 
Why "Otherwise"? I'm guessing that what is really meant is this:
 
* If either `mouse-autoselect-window' or `focus-follows-mouse' is
  non-nil, then move the mouse pointer to....
* Otherwise, do not move the mouse pointer.
 

Similar problems exist for the description in the Elisp manual (the
text is almost the same).  In addition, the manual should say
something more about the differences between these two functions, and
mention when you might use one or the other.
 
 
 
In GNU Emacs 23.0.96.1 (i386-mingw-nt5.1.2600)
 of 2009-07-09 on SOFT-MJASON
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'
 

Message #10 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Bastien <bastienguerry <at> googlemail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 3931 <at> debbugs.gnu.org, <emacs-pretest-bug <at> gnu.org>
Subject: Re: bug#3931: 23.0.96; doc of select-frame-set-input-focus and select-frame
Date: Mon, 27 Jul 2009 03:22:40 +0800

"Drew Adams" <drew.adams <at> oracle.com> writes:

> "If you are using a window system, the previously selected frame may
> be restored as the selected frame after return to the command loop..."
>  
> That's grammatically incorrect - "return" should presumably be
> "returning" (depending on what is intended by the sentence).
>  
> In any case, this paragraph of the description is not very clear.

I have changed it to this:

  "If you are using a window system, the previously selected frame may
  be restored as the selected frame when returning to the command loop,
  because it still may have the window system's input focus."

> Doc string of `select-frame-set-input-focus':
>  
> "If `mouse-autoselect-window' is non-nil, also move mouse cursor to
> FRAME's selected window.  Otherwise, if `focus-follows-mouse' is
> non-nil, move mouse cursor to FRAME."
>  
> "Mouse cursor" is incorrect; "pointer" is correct (or "mouse pointer",
> but, strictly speaking, "mouse" is redundant for the pointer).

Right, I changed this.

> Why "Otherwise"? 

Because the value of `focus-follows-mouse' is only checked if
`mouse-autoselect-window' is nil.

> Similar problems exist for the description in the Elisp manual (the
> text is almost the same).  In addition, the manual should say
> something more about the differences between these two functions, and
> mention when you might use one or the other.

I don't know how to fix the Elisp manual.

-- 
 Bastien

Message #20 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Bastien'" <bastienguerry <at> googlemail.com>
Cc: <3931 <at> debbugs.gnu.org>, <emacs-pretest-bug <at> gnu.org>
Subject: RE: bug#3931: 23.0.96; doc of select-frame-set-input-focus and select-frame
Date: Sun, 26 Jul 2009 12:33:38 -0700

> > Doc string of `select-frame-set-input-focus':
> > "If `mouse-autoselect-window' is non-nil, also move mouse cursor to
> > FRAME's selected window.  Otherwise, if `focus-follows-mouse' is
> > non-nil, move mouse cursor to FRAME."
> >  
> > Why "Otherwise"? 
> 
> Because the value of `focus-follows-mouse' is only checked if
> `mouse-autoselect-window' is nil.

OK, in that case the text is correct. But it could easily be misread by some
users. It would be clearer to state this explicitly: "If
`mouse-autoselect-window' is nil and `mouse-autoselect-window' is non-nil, then
move the mouse pointer to FRAME."

And it wouldn't hurt to state this explicitly also:
"Otherwise, do not move the mouse pointer."

> > Similar problems exist for the description in the Elisp manual (the
> > text is almost the same).  In addition, the manual should say
> > something more about the differences between these two 
> functions, and
> > mention when you might use one or the other.
> 
> I don't know how to fix the Elisp manual.

Hopefully, someone else does. ;-)

Thx.

Message #28 received at 3931 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 3931 <at> debbugs.gnu.org
Subject: Re: 23.0.96; doc of select-frame-set-input-focus and select-frame
Date: Tue, 12 Jul 2011 22:02:07 +0200

"Drew Adams" <drew.adams <at> oracle.com> writes:

> "Mouse cursor" is incorrect; "pointer" is correct (or "mouse pointer",
> but, strictly speaking, "mouse" is redundant for the pointer).
>
> Why "Otherwise"? I'm guessing that what is really meant is this:
>
> * If either `mouse-autoselect-window' or `focus-follows-mouse' is
>   non-nil, then move the mouse pointer to....
> * Otherwise, do not move the mouse pointer.
>
> Similar problems exist for the description in the Elisp manual (the
> text is almost the same).  In addition, the manual should say
> something more about the differences between these two functions, and
> mention when you might use one or the other.

I'm unable to find wording of this kind in the manual.  Has this been
fixed now?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #31 received at 3931 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Lars Magne Ingebrigtsen'" <larsi <at> gnus.org>
Cc: 3931 <at> debbugs.gnu.org
Subject: RE: 23.0.96; doc of select-frame-set-input-focus and select-frame
Date: Tue, 12 Jul 2011 14:11:38 -0700

> > Why "Otherwise"? I'm guessing that what is really meant is this:
> >
> > * If either `mouse-autoselect-window' or `focus-follows-mouse' is
> >   non-nil, then move the mouse pointer to....
> > * Otherwise, do not move the mouse pointer.
> >
> > Similar problems exist for the description in the Elisp manual (the
> > text is almost the same).  In addition, the manual should say
> > something more about the differences between these two 
> > functions, and mention when you might use one or the other.
> 
> I'm unable to find wording of this kind in the manual.  Has this been
> fixed now?

I don't know what I meant by the first sentence in the last paragraph, sorry.

But please fix the doc string as indicated.  And please explain in the Elisp
manual what the difference is between these two functions.  Thx.

Message #36 received at 3931 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'GNU bug Tracking System'" <help-debbugs <at> gnu.org>,
	"'Chong Yidong'" <cyd <at> gnu.org>, <3931 <at> debbugs.gnu.org>
Cc: tracker <at> debbugs.gnu.org
Subject: RE: [debbugs-tracker] Processed: close 3931
Date: Sat, 28 Jan 2012 06:32:33 -0800

This bug seems to have been closed with no explanation.  At least I received no
other message associated with the closing, apart from the equally empty of
explanation "acknowledged by developer" message.

Was this bug fixed?

> From: GNU bug Tracking System Sent: Friday, January 27, 2012 8:30 PM
> To: Chong Yidong Cc: tracker <at> debbugs.gnu.org
> Subject: [debbugs-tracker] Processed: close 3931
> 
> Processing commands for control <at> debbugs.gnu.org:
> 
> > close 3931
> bug#3931: 23.0.96; doc of select-frame-set-input-focus and 
> select-frame
> bug closed, send any further explanations to
> 3931 <at> debbugs.gnu.org and "Drew Adams" <drew.adams <at> oracle.com>
> 
> > thanks
> Stopping processing here.
> 
> Please contact help-debbugs <at> gnu.org if you need assistance.
> 
> GNU bugs database, http://debbugs.gnu.org/

Message #39 received at 3931 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <3931 <at> debbugs.gnu.org>
Subject: bug#3931: 23.0.96;
	doc of select-frame-set-input-focus and select-frame
Date: Sat, 28 Jan 2012 21:23:29 -0800

Subject: RE: [debbugs-tracker] Processed: close 3931

This bug seems to have been closed with no explanation.  At least I received no
other message associated with the closing, apart from the equally empty of
explanation "acknowledged by developer" message.

Was this bug fixed?

> From: GNU bug Tracking System Sent: Friday, January 27, 2012 8:30 PM
> To: Chong Yidong Cc: tracker <at> debbugs.gnu.org
> Subject: [debbugs-tracker] Processed: close 3931
> 
> Processing commands for control <at> debbugs.gnu.org:
> 
> > close 3931
> bug#3931: 23.0.96; doc of select-frame-set-input-focus and 
> select-frame
> bug closed, send any further explanations to
> 3931 <at> debbugs.gnu.org and "Drew Adams" <drew.adams <at> oracle.com>
> 
> > thanks
> Stopping processing here.
> 
> Please contact help-debbugs <at> gnu.org if you need assistance.
> 
> GNU bugs database, http://debbugs.gnu.org/

Message #42 received at 3931 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: Chong Yidong <cyd <at> gnu.org>
Cc: Drew Adams <drew.adams <at> oracle.com>, 3931 <at> debbugs.gnu.org
Subject: Re: close 3931 (doc of select-frame-set-input-focus and select-frame)
Date: Sun, 29 Jan 2012 15:05:07 -0700

Hello Chong,

Chong Yidong wrote:
> close 3931
> thanks

You have used the close command to close the an open bug and did not
provide any additional information.  Please could you say why you
think this bug should be closed?  Has the bug been fixed?  Is the bug
no longer relevant?  Have you committed a change that addesses this?

Note that when you use a 'close' command to close a bug report a
simple notification of action is sent to the user who submitted the
bug.  If you choose to close a bug this way please ensure that the
user is also notified of why the action is taken.  Otherwise the bug
submitter has no information.  This can be very frustrating.  See the
documentation for the 'close' command to see that it explicitly calls
out this use case as a problem and asks maintainers to ensure that
they communicate, probably by sending a separate message, why the bug
is being closed.
  
  See the section 'close bugnumber'
  http://debbugs.gnu.org/server-control.html

Thanks,
Bob

Message #45 received at 3931 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: 3931 <at> debbugs.gnu.org
Cc: Bob Proulx <bob <at> proulx.com>, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#3931: close 3931 (doc of select-frame-set-input-focus and
	select-frame)
Date: Mon, 30 Jan 2012 08:49:57 +0800

Bob Proulx <bob <at> proulx.com> writes:

> Has the bug been fixed?  Is the bug no longer relevant?  Have you
> committed a change that addesses this?

Yes.

Message #46 received at 3931-done <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 3931-done <at> debbugs.gnu.org
Subject: Re: bug#3931: 23.0.96;
	doc of select-frame-set-input-focus and select-frame
Date: Mon, 30 Jan 2012 09:16:23 +0800

"Drew Adams" <drew.adams <at> oracle.com> writes:

> This bug seems to have been closed with no explanation.  At least I
> received no other message associated with the closing, apart from the
> equally empty of explanation "acknowledged by developer" message.
>
> Was this bug fixed?

The tag had been marked "wontfix", and after reviewing it, I concluded
that no further action on this issue is necessary or desireable.  To
satisfy your curiosity: the bug-gnu-emacs archive link is present in the
manual, but adding URLs for finding help for Emacs is pointless since
there are tons of resources out there and we can't list them all in the
manual.

Closing.

Message #47 received at 3931-done <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Chong Yidong'" <cyd <at> gnu.org>
Cc: 3931-done <at> debbugs.gnu.org
Subject: RE: bug#3931: 23.0.96;
	doc of select-frame-set-input-focus and select-frame
Date: Sun, 29 Jan 2012 20:49:59 -0800

> > Was this bug fixed?
> 
> The tag had been marked "wontfix", and after reviewing it, I concluded
> that no further action on this issue is necessary or desireable.

FYI, the doc string still says "mouse cursor".  You corrected one occurrence of
that but you seem to have missed the other.

> To satisfy your curiosity: the bug-gnu-emacs archive link is 
> present in the manual, but adding URLs for finding help for
> Emacs is pointless since there are tons of resources out there
> and we can't list them all in the manual.

Sorry, I have no idea what you are talking about here.  What "bug-gnu-emacs
archive link"?  Where in the manual?  Who said anything about adding URLs for
finding help?  What's that all about?

Did you perhaps confuse this bug with another one?  Sorry, I just don't follow.

Message #50 received at 3931 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Chong Yidong'" <cyd <at> gnu.org>, <3931 <at> debbugs.gnu.org>
Cc: 'Bob Proulx' <bob <at> proulx.com>
Subject: RE: bug#3931: close 3931 (doc of select-frame-set-input-focus and
	select-frame)
Date: Sun, 29 Jan 2012 20:58:58 -0800

> > Has the bug been fixed?  Is the bug no longer relevant?  Have you
> > committed a change that addesses this?
> 
> Yes.

Hm.  "Yes", meaning what?  What change was committed that addresses it?

You tagged it "wontfix".  How does "wontfix" fit "has been fixed"?  What am I
missing?

From your separate mail to me just now:

 The tag had been marked "wontfix", and after reviewing it,
 I concluded that no further action on this issue is necessary
 or desireable.

That's your call.  I just don't see how that jibes with saying that the bug has
been fixed.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.