GNU bug report logs -
#44929
28.0.50; Info-next-reference skips next reference
Previous Next
Reported by: Stephen Berman <stephen.berman <at> gmx.net>
Date: Sat, 28 Nov 2020 19:23:02 UTC
Severity: normal
Found in version 28.0.50
Done: Stephen Berman <stephen.berman <at> gmx.net>
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 44929 in the body.
You can then email your comments to 44929 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#44929
; Package
emacs
.
(Sat, 28 Nov 2020 19:23:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stephen Berman <stephen.berman <at> gmx.net>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sat, 28 Nov 2020 19:23:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
0. emacs -Q
1. C-h r (if emacs is installed, otherwise `C-u h i /path/to/emacs.info
RET')
2. Repeat `C-n' until the cursor is on the '*' before the first menu
item 'Distrib'.
3. Type TAB
=> The cursor jumps over 'Distrib' and goes to the second menu item
'Intro'.
The same thing happens if the cursor is on the space between '*' and
'Distrib' and you then press TAB. In both cases, I expected the cursor
to go to the immediately following link instead of skipping it. This
behavior annoys me every time I run into it, but I haven't debugged it
till now. The attached patch fixes it. (The code responsible for the
current behavior in Info-next-reference has not changed since the
command was added to Emacs, but I hope you'll nevertheless agree it's a
bug.)
In GNU Emacs 28.0.50 (build 42, x86_64-pc-linux-gnu, GTK+ Version 3.24.17, cairo version 1.17.3)
of 2020-11-21 built on strobe-jhalfs
Repository revision: 0a8cd0116204354e95fbb4ebde64c58123502aa2
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Linux From Scratch SVN-20200401
Configured using:
'configure --with-xwidgets 'CFLAGS=-Og -g3'
PKG_CONFIG_PATH=/opt/qt5/lib/pkgconfig'
Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS
GTK3 X11 XDBE XIM MODULES THREADS XWIDGETS LIBSYSTEMD PDUMPER LCMS2
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
[Info-next-reference.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44929
; Package
emacs
.
(Sat, 28 Nov 2020 19:45:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 44929 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Date: Sat, 28 Nov 2020 20:21:50 +0100
>
> 0. emacs -Q
> 1. C-h r (if emacs is installed, otherwise `C-u h i /path/to/emacs.info
> RET')
> 2. Repeat `C-n' until the cursor is on the '*' before the first menu
> item 'Distrib'.
> 3. Type TAB
> => The cursor jumps over 'Distrib' and goes to the second menu item
> 'Intro'.
>
> The same thing happens if the cursor is on the space between '*' and
> 'Distrib' and you then press TAB. In both cases, I expected the cursor
> to go to the immediately following link instead of skipping it.
AFAIU, your expectation is wrong: TAB runs the command
Info-next-reference, where the "next" part means "not the current
one". For the "current" reference, press RET.
The stand-alone Info reader behaves the same. So this is not a bug,
and I don't think we can change that in Emacs, even if we'd agree with
you (and I don't think I do).
Thanks.
Reply sent
to
Stephen Berman <stephen.berman <at> gmx.net>
:
You have taken responsibility.
(Sat, 28 Nov 2020 19:55:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Stephen Berman <stephen.berman <at> gmx.net>
:
bug acknowledged by developer.
(Sat, 28 Nov 2020 19:55:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 44929-done <at> debbugs.gnu.org (full text, mbox):
On Sat, 28 Nov 2020 21:44:19 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Date: Sat, 28 Nov 2020 20:21:50 +0100
>>
>> 0. emacs -Q
>> 1. C-h r (if emacs is installed, otherwise `C-u h i /path/to/emacs.info
>> RET')
>> 2. Repeat `C-n' until the cursor is on the '*' before the first menu
>> item 'Distrib'.
>> 3. Type TAB
>> => The cursor jumps over 'Distrib' and goes to the second menu item
>> 'Intro'.
>>
>> The same thing happens if the cursor is on the space between '*' and
>> 'Distrib' and you then press TAB. In both cases, I expected the cursor
>> to go to the immediately following link instead of skipping it.
>
> AFAIU, your expectation is wrong: TAB runs the command
> Info-next-reference, where the "next" part means "not the current
> one". For the "current" reference, press RET.
I didn't know that RET works anywhere on the line (or lines) of the menu
item, not just on the link, and it never occurred to me to try. Thanks
for enlightening me. Closing.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44929
; Package
emacs
.
(Sat, 28 Nov 2020 20:12:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 44929-done <at> debbugs.gnu.org (full text, mbox):
> > AFAIU, your expectation is wrong: TAB runs the command
> > Info-next-reference, where the "next" part means "not the current
> > one". For the "current" reference, press RET.
>
> I didn't know that RET works anywhere on the line (or lines) of the
> menu item, not just on the link, and it never occurred to me to try.
How about improving `C-h k RET' here, to let
users know that? Neither the command name
nor the doc string really suggests that. IOW,
can we please elaborate about "near point"?
What's more, though some of the doc string says
"near point", other parts say "on".
"If point is on a reference..."
"If point is in a menu item..."
And this mistakenly says that "point" is "on",
or "in" something, whereas point is a position,
not something that is at, on, or in something
else. It's the other way around: something is
_at_ a position (such as point).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44929
; Package
emacs
.
(Sat, 28 Nov 2020 20:23:01 GMT)
Full text and
rfc822 format available.
Message #19 received at 44929 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 28 Nov 2020 12:10:57 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 44929-done <at> debbugs.gnu.org
>
> How about improving `C-h k RET' here, to let
> users know that? Neither the command name
> nor the doc string really suggests that. IOW,
> can we please elaborate about "near point"?
>
> What's more, though some of the doc string says
> "near point", other parts say "on".
>
> "If point is on a reference..."
> "If point is in a menu item..."
>
> And this mistakenly says that "point" is "on",
> or "in" something, whereas point is a position,
> not something that is at, on, or in something
> else. It's the other way around: something is
> _at_ a position (such as point).
Pedant.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44929
; Package
emacs
.
(Sat, 28 Nov 2020 20:57:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 44929 <at> debbugs.gnu.org (full text, mbox):
> Pedant.
Ad hominem.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 27 Dec 2020 12:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 171 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.