bug#61781: 28.2; (setq-default indent-tabs-mode nil) causes weird next-line behavior in *Help*

bug#61781: 28.2; (setq-default indent-tabs-mode nil) causes weird next-line behavior in *Help*

[Spencer Baugh]

From emacs -Q:

1. M-: (setq-default indent-tabs-mode nil) RET
2. Open up a help buffer, e.g. C-x 4 C-h
3. Move point to the link for the first binding (find-file-other-window)
4. C-n
5. Observe that in addition to moving down, point also moves back one
   column (as if we had hit C-b).

Without indent-tabs-mode set to nil, next-line stays in the same column.

In GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.15.12, Xaw scroll bars)
 of 2023-02-09 built on myhost
Repository revision: 739b5d0e52d83ec567bd61a5a49ac0e93e0eb469
Repository branch: HEAD
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: CentOS Linux 7 (Core)

Configured using:
 'configure --with-x-toolkit=lucid --without-gpm --without-gconf
 --without-selinux --without-imagemagick --with-modules --with-gif=no
 --with-cairo --with-rsvg'

Configured features:
CAIRO DBUS FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LIBXML2
MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF
TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM LUCID ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Help

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils help-mode
cl-loaddefs cl-lib iso-transl tooltip eldoc paren electric uniquify
ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo x-toolkit
x multi-tty make-network-process emacs)

Memory information:
((conses 16 52274 9662)
 (symbols 48 6734 1)
 (strings 32 19259 922)
 (string-bytes 1 634660)
 (vectors 16 12973)
 (vector-slots 8 180318 12801)
 (floats 8 28 113)
 (intervals 56 334 1)
 (buffers 992 12)
 (heap 1024 12312 3225))

bug#61781: 28.2; (setq-default indent-tabs-mode nil) causes weird next-line behavior in *Help*

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Fri, 24 Feb 2023 17:32:09 -0500
> 
> >From emacs -Q:
> 
> 1. M-: (setq-default indent-tabs-mode nil) RET
> 2. Open up a help buffer, e.g. C-x 4 C-h
> 3. Move point to the link for the first binding (find-file-other-window)
> 4. C-n
> 5. Observe that in addition to moving down, point also moves back one
>    column (as if we had hit C-b).
> 
> Without indent-tabs-mode set to nil, next-line stays in the same column.

I can reproduce this in Emacs 28.2, but not in Emacs 29, since
describe-prefix-bindings in Emacs 29 no longer heeds indent-tabs-mode,
it always inserts tabs.  So if this problem still exists in Emacs 29,
you or someone else will have to come up with a different reproducer.

Thanks.

bug#61781: 28.2; (setq-default indent-tabs-mode nil) causes weird next-line behavior in *Help*

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Date: Fri, 24 Feb 2023 17:32:09 -0500
>>
>> >From emacs -Q:
>>
>> 1. M-: (setq-default indent-tabs-mode nil) RET
>> 2. Open up a help buffer, e.g. C-x 4 C-h
>> 3. Move point to the link for the first binding (find-file-other-window)
>> 4. C-n
>> 5. Observe that in addition to moving down, point also moves back one
>>    column (as if we had hit C-b).
>>
>> Without indent-tabs-mode set to nil, next-line stays in the same column.
>
> I can reproduce this in Emacs 28.2, but not in Emacs 29, since
> describe-prefix-bindings in Emacs 29 no longer heeds indent-tabs-mode,
> it always inserts tabs.  So if this problem still exists in Emacs 29,
> you or someone else will have to come up with a different reproducer.

Ping.  Specer, is this an issue for you in Emacs 29?  If so, could you
come up with a different reproducer?  Thanks in advance.

bug#61781: 28.2; (setq-default indent-tabs-mode nil) causes weird next-line behavior in *Help*

[Spencer Baugh]

Stefan Kangas <stefankangas@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Spencer Baugh <sbaugh@janestreet.com>
>>> Date: Fri, 24 Feb 2023 17:32:09 -0500
>>>
>>> >From emacs -Q:
>>>
>>> 1. M-: (setq-default indent-tabs-mode nil) RET
>>> 2. Open up a help buffer, e.g. C-x 4 C-h
>>> 3. Move point to the link for the first binding (find-file-other-window)
>>> 4. C-n
>>> 5. Observe that in addition to moving down, point also moves back one
>>>    column (as if we had hit C-b).
>>>
>>> Without indent-tabs-mode set to nil, next-line stays in the same column.
>>
>> I can reproduce this in Emacs 28.2, but not in Emacs 29, since
>> describe-prefix-bindings in Emacs 29 no longer heeds indent-tabs-mode,
>> it always inserts tabs.  So if this problem still exists in Emacs 29,
>> you or someone else will have to come up with a different reproducer.
>
> Ping.  Specer, is this an issue for you in Emacs 29?  If so, could you
> come up with a different reproducer?  Thanks in advance.

I managed to reproduce this in Emacs 28 even without indent-tabs-mode,
but it was fixed in Emacs 29 in c825c825256475ac5c74882811a44228140f18ee
by changing the help-key-binding face to draw a thinner box.
1b30b4dbc0dcaac02e5a15ff53da476e4680aced actually adds a comment
describing exactly this issue and how the previous change fixed it :)

So this can be closed.

bug#61781: 28.2; (setq-default indent-tabs-mode nil) causes weird next-line behavior in *Help*

[Stefan Kangas]

Spencer Baugh <sbaugh@janestreet.com> writes:

> I managed to reproduce this in Emacs 28 even without indent-tabs-mode,
> but it was fixed in Emacs 29 in c825c825256475ac5c74882811a44228140f18ee
> by changing the help-key-binding face to draw a thinner box.
> 1b30b4dbc0dcaac02e5a15ff53da476e4680aced actually adds a comment
> describing exactly this issue and how the previous change fixed it :)
>
> So this can be closed.

Thanks for reporting back.  I'm therefore closing this bug report.