GNU bug report logs -
#12922
24.3.50; `make-pointer-invisible' don't seem to work
Previous Next
Reported by: Dani Moncayo <dmoncayo <at> gmail.com>
Date: Sun, 18 Nov 2012 12:38:02 UTC
Severity: wishlist
Found in version 24.3.50
Fixed in version 25.1
Done: martin rudalics <rudalics <at> gmx.at>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12922 in the body.
You can then email your comments to 12922 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12922
; Package
emacs
.
(Sun, 18 Nov 2012 12:38:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Dani Moncayo <dmoncayo <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sun, 18 Nov 2012 12:38:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi,
(Maybe I'm missing something, but I fail to see what)
I've read this paragraph in (info "(emacs) Display Custom"):
If the mouse pointer lies inside an Emacs frame, Emacs makes it
invisible each time you type a character to insert text, to prevent it
from obscuring the text. (To be precise, the hiding occurs when you
type a "self-inserting" character. *Note Inserting Text::.) Moving
the mouse pointer makes it visible again. To disable this feature, set
the variable `make-pointer-invisible' to `nil'.
When I try to test that feature, the mouse pointer never hides. It
only changes between the arrow (when the pointer is over an empty
area) and the "I-beam" (when the pointer is over some text).
I've tested this with Emacs -Q, with the current trunk, with the
current emacs-24 branch, and with the 24.2, 24.1 and 23.4 releases.
In all cases the behavior is the same (mouse pointer remains visible
after typing text).
In GNU Emacs 24.3.50.1 (i386-mingw-nt6.1.7601)
of 2012-11-18 on MS-W7-DANI
Bzr revision: 110940 cyd <at> gnu.org-20121118053813-ijg6257029399jtu
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
`configure --with-gcc (4.7) --no-opt --enable-checking --cflags
-Ic:/emacs/libs/libXpm-3.5.10/include -Ic:/emacs/libs/libXpm-3.5.10/src
-Ic:/emacs/libs/libpng-1.2.37-lib/include -Ic:/emacs/libs/zlib-1.2.5
-Ic:/emacs/libs/giflib-4.1.4-1-lib/include
-Ic:/emacs/libs/jpeg-6b-4-lib/include
-Ic:/emacs/libs/tiff-3.8.2-1-lib/include
-Ic:/emacs/libs/libxml2-2.7.8-w32-bin/include/libxml2
-Ic:/emacs/libs/gnutls-3.0.9-w32-bin/include
-Ic:/emacs/libs/libiconv-1.9.2-1-lib/include'
Important settings:
value of $LANG: ENU
locale-coding-system: cp1252
default enable-multibyte-characters: t
--
Dani Moncayo
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12922
; Package
emacs
.
(Sun, 18 Nov 2012 15:32:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 12922 <at> debbugs.gnu.org (full text, mbox):
severity 12922 wishlist
stop
> Date: Sun, 18 Nov 2012 13:36:38 +0100
> From: Dani Moncayo <dmoncayo <at> gmail.com>
>
> I've read this paragraph in (info "(emacs) Display Custom"):
>
> If the mouse pointer lies inside an Emacs frame, Emacs makes it
> invisible each time you type a character to insert text, to prevent it
> from obscuring the text. (To be precise, the hiding occurs when you
> type a "self-inserting" character. *Note Inserting Text::.) Moving
> the mouse pointer makes it visible again. To disable this feature, set
> the variable `make-pointer-invisible' to `nil'.
>
> When I try to test that feature, the mouse pointer never hides. It
> only changes between the arrow (when the pointer is over an empty
> area) and the "I-beam" (when the pointer is over some text).
>
> I've tested this with Emacs -Q, with the current trunk, with the
> current emacs-24 branch, and with the 24.2, 24.1 and 23.4 releases.
> In all cases the behavior is the same (mouse pointer remains visible
> after typing text).
This feature is not currently supported on MS-Windows. I marked this
"wishlist"; patches are welcome.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12922
; Package
emacs
.
(Sun, 18 Nov 2012 15:40:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 12922 <at> debbugs.gnu.org (full text, mbox):
> This feature is not currently supported on MS-Windows. I marked this
> "wishlist"; patches are welcome.
Ok.
I suggest putting this clarification in the documentation (docstring
and manual) while this feature is not available on MS-Windows.
--
Dani Moncayo
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12922
; Package
emacs
.
(Sun, 18 Nov 2012 15:56:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 12922 <at> debbugs.gnu.org (full text, mbox):
> > This feature is not currently supported on MS-Windows. I
> > marked this "wishlist"; patches are welcome.
>
> I suggest putting this clarification in the documentation (docstring
> and manual) while this feature is not available on MS-Windows.
+1
There are also other things regarding the mouse pointer that are not supported
on Windows. They too should should be pointed out. I have seen more than one
user try to change the pointer attributes in vain.
Severity set to 'wishlist' from 'normal'
Request was from
Eli Zaretskii <eliz <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Sun, 18 Nov 2012 17:11:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12922
; Package
emacs
.
(Sun, 18 Nov 2012 17:13:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 12922 <at> debbugs.gnu.org (full text, mbox):
> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <12922 <at> debbugs.gnu.org>
> Date: Sun, 18 Nov 2012 07:54:35 -0800
>
> > > This feature is not currently supported on MS-Windows. I
> > > marked this "wishlist"; patches are welcome.
> >
> > I suggest putting this clarification in the documentation (docstring
> > and manual) while this feature is not available on MS-Windows.
>
> +1
We don't normally do that in the manuals, but feel free to suggest
changes, perhaps Stefan or Chong will accept them.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12922
; Package
emacs
.
(Sun, 18 Nov 2012 19:41:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 12922 <at> debbugs.gnu.org (full text, mbox):
>> > > This feature is not currently supported on MS-Windows. I
>> > > marked this "wishlist"; patches are welcome.
>> >
>> > I suggest putting this clarification in the documentation (docstring
>> > and manual) while this feature is not available on MS-Windows.
>>
>> +1
>
> We don't normally do that in the manuals, but feel free to suggest
> changes, perhaps Stefan or Chong will accept them.
Not sure about the docstrings, but the Emacs Manual has many
references to MS-Windows, explaining things specific to that platform,
which obviously is TRT, as that is a supported platform.
The very reason for filing this bug report was that I read about a
feature that didn't work for me. If the documentation had been
accurate, I wouldn't have had to send this bug report.
IOW, this is a documentation bug. So, why not fixing it?
--
Dani Moncayo
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12922
; Package
emacs
.
(Sun, 18 Nov 2012 21:15:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 12922 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 18 Nov 2012 20:39:44 +0100
> From: Dani Moncayo <dmoncayo <at> gmail.com>
> Cc: Drew Adams <drew.adams <at> oracle.com>, 12922 <at> debbugs.gnu.org
>
> >> > > This feature is not currently supported on MS-Windows. I
> >> > > marked this "wishlist"; patches are welcome.
> >> >
> >> > I suggest putting this clarification in the documentation (docstring
> >> > and manual) while this feature is not available on MS-Windows.
> >>
> >> +1
> >
> > We don't normally do that in the manuals, but feel free to suggest
> > changes, perhaps Stefan or Chong will accept them.
>
> Not sure about the docstrings, but the Emacs Manual has many
> references to MS-Windows, explaining things specific to that platform,
> which obviously is TRT, as that is a supported platform.
No, I meant we don't normally say in the manual "this and that feature
is not (yet) implemented on this and that platform." Especially if
that platform is Windows.
> The very reason for filing this bug report was that I read about a
> feature that didn't work for me. If the documentation had been
> accurate, I wouldn't have had to send this bug report.
>
> IOW, this is a documentation bug. So, why not fixing it?
Because it's not a documentation bug. It's a feature that's missing
on one particular platform.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12922
; Package
emacs
.
(Sun, 18 Nov 2012 21:38:01 GMT)
Full text and
rfc822 format available.
Message #28 received at 12922 <at> debbugs.gnu.org (full text, mbox):
>> > We don't normally do that in the manuals, but feel free to suggest
>> > changes, perhaps Stefan or Chong will accept them.
>>
>> Not sure about the docstrings, but the Emacs Manual has many
>> references to MS-Windows, explaining things specific to that platform,
>> which obviously is TRT, as that is a supported platform.
>
> No, I meant we don't normally say in the manual "this and that feature
> is not (yet) implemented on this and that platform." Especially if
> that platform is Windows.
I don't see the point of not doing that.
>> The very reason for filing this bug report was that I read about a
>> feature that didn't work for me. If the documentation had been
>> accurate, I wouldn't have had to send this bug report.
>>
>> IOW, this is a documentation bug. So, why not fixing it?
>
> Because it's not a documentation bug. It's a feature that's missing
> on one particular platform.
To me, a documentation bug is a bug in the documentation, i.e., the
program's behavior is the intended one, but the documentation doesn't
describes that behavior. And that is what happens here.
Definitions aside, the fact is that currently, any user of the
MS-Windows port of Emacs will be confused when she reads about the
`make-pointer-invisible' variable and notice that the actual behavior
of the program does not match the documentation.
--
Dani Moncayo
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12922
; Package
emacs
.
(Sun, 18 Nov 2012 21:49:01 GMT)
Full text and
rfc822 format available.
Message #31 received at 12922 <at> debbugs.gnu.org (full text, mbox):
> a bug in the documentation, i.e., the program's behavior is
> the intended one, but the documentation doesn't
> describes that behavior. And that is what happens here.
>
> Definitions aside, the fact is that currently, any user of the
> MS-Windows port of Emacs will be confused when she reads about the
> `make-pointer-invisible' variable and notice that the actual behavior
> of the program does not match the documentation.
If it is not possible to update the doc wrt specific platforms here and there,
describing specific limitations per platform, perhaps it would at least be
possible in some cases (like this one) to state that the feature (whatever it is
- making the pointer invisible, for instance) "might not be available on some
platforms".
That would at least give readers a heads-up, so they do not completely wonder
what's going on and whether (a) there is perhaps a product bug or (b) they are
perhaps misreading the doc.
Yes, such a weak caveat is true for nearly all features. But this is not
something black-and-white, all-or-nothing.
If such caveats are used judiciously, i.e., only in places where we in fact do
not support a feature on some platform (especially a commonly used platform) and
where we realize there might well be a chance for reader confusion, then I, for
one, think they could be helpful.
Reply sent
to
martin rudalics <rudalics <at> gmx.at>
:
You have taken responsibility.
(Mon, 06 Jul 2015 11:05:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Dani Moncayo <dmoncayo <at> gmail.com>
:
bug acknowledged by developer.
(Mon, 06 Jul 2015 11:05:03 GMT)
Full text and
rfc822 format available.
Message #36 received at 12922-done <at> debbugs.gnu.org (full text, mbox):
Version: 25.1
> I've read this paragraph in (info "(emacs) Display Custom"):
>
> If the mouse pointer lies inside an Emacs frame, Emacs makes it
> invisible each time you type a character to insert text, to prevent it
> from obscuring the text. (To be precise, the hiding occurs when you
> type a "self-inserting" character. *Note Inserting Text::.) Moving
> the mouse pointer makes it visible again. To disable this feature, set
> the variable `make-pointer-invisible' to `nil'.
>
> When I try to test that feature, the mouse pointer never hides. It
> only changes between the arrow (when the pointer is over an empty
> area) and the "I-beam" (when the pointer is over some text).
>
> I've tested this with Emacs -Q, with the current trunk, with the
> current emacs-24 branch, and with the 24.2, 24.1 and 23.4 releases.
> In all cases the behavior is the same (mouse pointer remains visible
> after typing text).
>
>
> In GNU Emacs 24.3.50.1 (i386-mingw-nt6.1.7601)
> of 2012-11-18 on MS-W7-DANI
This should work with Emacs 25.1. Bug closed.
Thanks, martin
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 03 Aug 2015 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 9 years and 323 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.