GNU bug report logs - #43835
28.0.50; auto-hscroll-mode/current-line + show-paren-mode + gnus-summary-mode = bug

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 43835 in the body.
You can then email your comments to 43835 AT debbugs.gnu.org in the normal way.

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

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; auto-hscroll-mode/current-line + show-paren-mode +
 gnus-summary-mode = bug
Date: Tue, 06 Oct 2020 20:53:53 +0200

[Message part 1 (text/plain, inline)]

I have observed a quirk in auto hscrolling the current line under
specific conditions.  I have only seen it in gnus-summary-mode, but
there can reproduce it reliably with the following recipe:

0. Save the attached email to a file.
1. emacs -Q
2. Type `M-x gnus' and enter `y' at the prompt to continue.
3. Type `Gf' and at the prompt enter the saved email file and then RET.
4. You should now be in the Gnus group buffer showing a document group
   created from that file; press RET to enter the group.  You should now
   be in a Gnus summary buffer containing only one line listing the
   saved email with point on that line.
5. Type `M-x customize-option RET auto-hscroll-mode RET' and in the
   Custom buffer select `Scroll only the current line' from the Value
   Menu and `Set for current session' from the State menu.  Type `q' to
   return to the Gnus summary buffer.
6. As a sanity check, type `C-e', moving point to the end of the line,
   which contains the email Subject line ending with `(this is a
   test)'.  Notice that the line remains scrolled with point after the
   closing paren: (point) -> 119.  Type `C-a' to move point to the
   beginning of the line.
7. From the Options menu check the item `Highlight Matching Parentheses'.
8. Type `C-e' again.
=> You should see the line scroll left to show the end of the line and
   then immediately scroll back, but with point remaining at 119, so the
   cursor is not visible.
9. If you now uncheck `Highlight Matching Parentheses' in the Options
   menu, hscrolling works again as expected, as in step 6.

I can reproduce this problem in Emacs 26, 27 and master, but I have only
been able to reproduce it in Gnus summary buffers, and only on the last
line of the summary and only when this line is longer than window-width
(so that hscrolling can happen) and the line ends with a pair of paren
characters (brackets and braces also show the effect) and
show-paren-mode is enabled.  Sometimes I have seen the hscroll get
restored after a several seconds, but other times this does not happen
(though I haven't tried waiting for more than maybe 15-20 seconds).
Non-final lines in the summary buffer that end with paren characters do
not show the anomalous hscrolling.  When I copy such a line to another
buffer and change that buffer's major mode to gnus-summary-mode, I
cannot reproduce the problem.


In GNU Emacs 28.0.50 (build 28, x86_64-pc-linux-gnu, GTK+ Version 3.24.17, cairo version 1.17.3)
 of 2020-10-06 built on strobe-jhalfs
Repository revision: bcd09e9869a3f371024286d25743ebaf17f0be9d
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Linux From Scratch SVN-20200401

Configured using:
 'configure '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 LIBSYSTEMD PDUMPER LCMS2

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

[test (application/octet-stream, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 43835 <at> debbugs.gnu.org
Subject: Re: bug#43835: 28.0.50;
 auto-hscroll-mode/current-line + show-paren-mode + gnus-summary-mode
 = bug
Date: Tue, 06 Oct 2020 22:10:26 +0300

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Date: Tue, 06 Oct 2020 20:53:53 +0200
> 
> I have observed a quirk in auto hscrolling the current line under
> specific conditions.  I have only seen it in gnus-summary-mode, but
> there can reproduce it reliably with the following recipe:

Thanks, but having Gnus in the picture is too much.  Debugging
redisplay issues involved in these momentary movements is hard as it
is already.

You could perhaps help me come up with ideas if, in a build configured
with --enable-checking='yes,glyphs', you did the following:

  emacs -Q
  M-x blink-cursor-mode RET
  M-x global-eldoc-mode RET

Then perform your recipe up to and excluding step 8.

  M-x trace-redisplay RET

Wait till there are no more messages printed to stderr, then perform
step 8 and notice the messages it causes to be printed, after you type
C-e.

Then do the same experiment, but with some other buffer, where you say
that the problem doesn't happen, and tell what messages were printed
by trace-redisplay in that case after C-e.  If there's any difference
between these two scenarios visible in the trace, that could give some
ideas regarding the possible cause(s).

Thanks.

> I can reproduce this problem in Emacs 26, 27 and master, but I have only
> been able to reproduce it in Gnus summary buffers, and only on the last
> line of the summary and only when this line is longer than window-width
> (so that hscrolling can happen) and the line ends with a pair of paren
> characters (brackets and braces also show the effect) and
> show-paren-mode is enabled.  Sometimes I have seen the hscroll get
> restored after a several seconds, but other times this does not happen
> (though I haven't tried waiting for more than maybe 15-20 seconds).

Does the hscroll get restored if you type "M-x"?

P.S. Please remember performing all these tests with both
blink-cursor-mode and global-eldoc-mode disabled.  Those two cause
frequent redisplay cycles that can completely obscure the actual
problems.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 43835 <at> debbugs.gnu.org
Subject: Re: bug#43835: 28.0.50; auto-hscroll-mode/current-line +
 show-paren-mode + gnus-summary-mode = bug
Date: Tue, 06 Oct 2020 22:05:42 +0200

On Tue, 06 Oct 2020 22:10:26 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Date: Tue, 06 Oct 2020 20:53:53 +0200
>>
>> I have observed a quirk in auto hscrolling the current line under
>> specific conditions.  I have only seen it in gnus-summary-mode, but
>> there can reproduce it reliably with the following recipe:
>
> Thanks, but having Gnus in the picture is too much.  Debugging
> redisplay issues involved in these momentary movements is hard as it
> is already.

I believe you, and I wish I could remove Gnus from the recipe (I've been
seeing this problem for at least three years, but only today did I
recognize that show-paren-mode was involved and so could reliably
reproduce it).

> You could perhaps help me come up with ideas if, in a build configured
> with --enable-checking='yes,glyphs', you did the following:
>
>   emacs -Q
>   M-x blink-cursor-mode RET
>   M-x global-eldoc-mode RET
>
> Then perform your recipe up to and excluding step 8.
>
>   M-x trace-redisplay RET
>
> Wait till there are no more messages printed to stderr, then perform
> step 8 and notice the messages it causes to be printed, after you type
> C-e.
>
> Then do the same experiment, but with some other buffer, where you say
> that the problem doesn't happen, and tell what messages were printed
> by trace-redisplay in that case after C-e.  If there's any difference
> between these two scenarios visible in the trace, that could give some
> ideas regarding the possible cause(s).
>
> Thanks.

Thanks for the suggestions, I'll try them as soon as I can and report back.

>> I can reproduce this problem in Emacs 26, 27 and master, but I have only
>> been able to reproduce it in Gnus summary buffers, and only on the last
>> line of the summary and only when this line is longer than window-width
>> (so that hscrolling can happen) and the line ends with a pair of paren
>> characters (brackets and braces also show the effect) and
>> show-paren-mode is enabled.  Sometimes I have seen the hscroll get
>> restored after a several seconds, but other times this does not happen
>> (though I haven't tried waiting for more than maybe 15-20 seconds).
>
> Does the hscroll get restored if you type "M-x"?

As soon as I type `M-x' I see the line scroll left and the cursor at the
end, and it remains like that, but if I then type `C-g', the line
scrolls back to the right and point is again not visible, as in step 8.

> P.S. Please remember performing all these tests with both
> blink-cursor-mode and global-eldoc-mode disabled.  Those two cause
> frequent redisplay cycles that can completely obscure the actual
> problems.

Ok.

Steve Berman

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 43835 <at> debbugs.gnu.org
Subject: Re: bug#43835: 28.0.50; auto-hscroll-mode/current-line +
 show-paren-mode + gnus-summary-mode = bug
Date: Tue, 06 Oct 2020 23:59:24 +0200

On Tue, 06 Oct 2020 22:05:42 +0200 Stephen Berman <stephen.berman <at> gmx.net> wrote:

> On Tue, 06 Oct 2020 22:10:26 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>>> I can reproduce this problem in Emacs 26, 27 and master, but I have only
>>> been able to reproduce it in Gnus summary buffers, and only on the last
>>> line of the summary and only when this line is longer than window-width
>>> (so that hscrolling can happen) and the line ends with a pair of paren
>>> characters (brackets and braces also show the effect) and
>>> show-paren-mode is enabled.  Sometimes I have seen the hscroll get
>>> restored after a several seconds, but other times this does not happen
>>> (though I haven't tried waiting for more than maybe 15-20 seconds).
>>
>> Does the hscroll get restored if you type "M-x"?
>
> As soon as I type `M-x' I see the line scroll left and the cursor at the
> end, and it remains like that, but if I then type `C-g', the line
> scrolls back to the right and point is again not visible, as in step 8.

I haven't yet rebuilt with --enable-checking='yes,glyphs', but I just
made a new, perhaps relevant, observation: after step 8 of the recipe,
i.e. with point at the end of the line but hscrolling undone, if I move
the mouse pointer to a position that pops up a tooltip (i.e., over a
tool-bar icon or a mode-line element), then with
x-gtk-use-system-tooltips set to t nothing changes but with
x-gtk-use-system-tooltips set to nil, the hscroll is restored, like with
`M-x' before `C-g', and the hscroll stays when I move the mouse so that
the tooltip vanishes, but if I then type `C-g', the hscroll is undone
again (and point remains at the end of the line, out of view).

Steve Berman

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 43835 <at> debbugs.gnu.org
Subject: Re: bug#43835: 28.0.50; auto-hscroll-mode/current-line +
 show-paren-mode + gnus-summary-mode = bug
Date: Wed, 07 Oct 2020 10:08:23 +0300

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: 43835 <at> debbugs.gnu.org
> Date: Tue, 06 Oct 2020 22:05:42 +0200
> 
> > Thanks, but having Gnus in the picture is too much.  Debugging
> > redisplay issues involved in these momentary movements is hard as it
> > is already.
> 
> I believe you, and I wish I could remove Gnus from the recipe

An alternative would be to figure out what display-related changes
made by Gnus in that buffer affect this.  Then we could use those
settings outside of Gnus to reproduce the issue.

> > Does the hscroll get restored if you type "M-x"?
> 
> As soon as I type `M-x' I see the line scroll left and the cursor at the
> end, and it remains like that

I'm not sure I understand: is that the correct display in this case?
If not, what is the correct display?

> but if I then type `C-g', the line scrolls back to the right and
> point is again not visible, as in step 8.

Weird...

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 43835 <at> debbugs.gnu.org
Subject: Re: bug#43835: 28.0.50; auto-hscroll-mode/current-line +
 show-paren-mode + gnus-summary-mode = bug
Date: Wed, 07 Oct 2020 10:25:27 +0300

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: 43835 <at> debbugs.gnu.org
> Date: Tue, 06 Oct 2020 23:59:24 +0200
> 
> >> Does the hscroll get restored if you type "M-x"?
> >
> > As soon as I type `M-x' I see the line scroll left and the cursor at the
> > end, and it remains like that, but if I then type `C-g', the line
> > scrolls back to the right and point is again not visible, as in step 8.
> 
> I haven't yet rebuilt with --enable-checking='yes,glyphs', but I just
> made a new, perhaps relevant, observation: after step 8 of the recipe,
> i.e. with point at the end of the line but hscrolling undone, if I move
> the mouse pointer to a position that pops up a tooltip (i.e., over a
> tool-bar icon or a mode-line element), then with
> x-gtk-use-system-tooltips set to t nothing changes but with
> x-gtk-use-system-tooltips set to nil, the hscroll is restored, like with
> `M-x' before `C-g', and the hscroll stays when I move the mouse so that
> the tooltip vanishes, but if I then type `C-g', the hscroll is undone
> again (and point remains at the end of the line, out of view).

I think popping up the native tooltip has the same effect as typing
M-x: both trigger a thorough redisplay cycle.  The more important fact
is that C-g "breaks" the display again, which is... unexpected.

Thanks.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: stephen.berman <at> gmx.net
Cc: 43835 <at> debbugs.gnu.org
Subject: Re: bug#43835: 28.0.50;
 auto-hscroll-mode/current-line + show-paren-mode + gnus-summary-mode
 = bug
Date: Wed, 07 Oct 2020 15:46:42 +0300

> Date: Wed, 07 Oct 2020 10:25:27 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 43835 <at> debbugs.gnu.org
> 
> > I haven't yet rebuilt with --enable-checking='yes,glyphs', but I just
> > made a new, perhaps relevant, observation: after step 8 of the recipe,
> > i.e. with point at the end of the line but hscrolling undone, if I move
> > the mouse pointer to a position that pops up a tooltip (i.e., over a
> > tool-bar icon or a mode-line element), then with
> > x-gtk-use-system-tooltips set to t nothing changes but with
> > x-gtk-use-system-tooltips set to nil, the hscroll is restored, like with
> > `M-x' before `C-g', and the hscroll stays when I move the mouse so that
> > the tooltip vanishes, but if I then type `C-g', the hscroll is undone
> > again (and point remains at the end of the line, out of view).
> 
> I think popping up the native tooltip has the same effect as typing
> M-x: both trigger a thorough redisplay cycle.  The more important fact
> is that C-g "breaks" the display again, which is... unexpected.

Could the reason for this problem somehow be related to
gnus-horizontal-recenter, which is called by gnus-recenter basically
whenever you do something in the summary buffer?  If you disable this
horizontal recentering (e.g., by setting gnus-auto-center-summary to
the value 'vertical'), does the problem go away?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: stephen.berman <at> gmx.net
Cc: 43835 <at> debbugs.gnu.org
Subject: Re: bug#43835: 28.0.50;
 auto-hscroll-mode/current-line + show-paren-mode + gnus-summary-mode
 = bug
Date: Wed, 07 Oct 2020 15:58:33 +0300

> Date: Wed, 07 Oct 2020 15:46:42 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 43835 <at> debbugs.gnu.org
> 
> Could the reason for this problem somehow be related to
> gnus-horizontal-recenter, which is called by gnus-recenter basically
> whenever you do something in the summary buffer?  If you disable this
> horizontal recentering (e.g., by setting gnus-auto-center-summary to
> the value 'vertical'), does the problem go away?

I think when auto-hscroll-mode is non-nil, gnus-horizontal-recenter
should do nothing, instead letting the automatic hscrolling to do its
thing.  At least when auto-hscroll-mode's value is 'current-line',
because in that case setting the window's hscroll value does the wrong
thing.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 43835 <at> debbugs.gnu.org
Subject: Re: bug#43835: 28.0.50; auto-hscroll-mode/current-line +
 show-paren-mode + gnus-summary-mode = bug
Date: Wed, 07 Oct 2020 22:54:51 +0200

On Wed, 07 Oct 2020 10:08:23 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: 43835 <at> debbugs.gnu.org
>> Date: Tue, 06 Oct 2020 22:05:42 +0200
>>
>> > Thanks, but having Gnus in the picture is too much.  Debugging
>> > redisplay issues involved in these momentary movements is hard as it
>> > is already.
>>
>> I believe you, and I wish I could remove Gnus from the recipe
>
> An alternative would be to figure out what display-related changes
> made by Gnus in that buffer affect this.  Then we could use those
> settings outside of Gnus to reproduce the issue.

I figured it out and you may be surprised.  Here's the new recipe:

0. emacs -Q
1. Evaluate the following sexp:

(let ((buf (get-buffer-create "*test*")))
  (with-current-buffer buf
    (setq auto-hscroll-mode 'current-line
	  truncate-lines t
	  bidi-paragraph-direction 'left-to-right)
    (insert "Subject: Re: bug#39280: 27.0.60; wdired-get-filename ignores first argument (this is a test)\n")
    (goto-char (point-min)))
  (show-paren-mode)
  (switch-to-buffer buf))

2. Now typing `C-e' shows the problem.

The settings of truncate-lines and bidi-paragraph-direction come from
gnus-summary-mode, the newline at the end of the inserted text is also
essential (I think I had omitted that when I though I couldn't replicate
the problem in another buffer).

Do you still want the output of trace-redisplay?

Steve Berman

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 43835 <at> debbugs.gnu.org
Subject: Re: bug#43835: 28.0.50; auto-hscroll-mode/current-line +
 show-paren-mode + gnus-summary-mode = bug
Date: Thu, 08 Oct 2020 11:22:38 +0300

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: 43835 <at> debbugs.gnu.org
> Date: Wed, 07 Oct 2020 22:54:51 +0200
> 
> 0. emacs -Q
> 1. Evaluate the following sexp:
> 
> (let ((buf (get-buffer-create "*test*")))
>   (with-current-buffer buf
>     (setq auto-hscroll-mode 'current-line
> 	  truncate-lines t
> 	  bidi-paragraph-direction 'left-to-right)
>     (insert "Subject: Re: bug#39280: 27.0.60; wdired-get-filename ignores first argument (this is a test)\n")
>     (goto-char (point-min)))
>   (show-paren-mode)
>   (switch-to-buffer buf))
> 
> 2. Now typing `C-e' shows the problem.

bidi-paragraph-direction is set to left-to-right in any descendant of
prog-mode, in particular in Emacs Lisp mode.  And yet I couldn't
reproduce this in a Lisp buffer, no matter what I tried.  So that
setting is not the only cause.

If you add a line of text before and after the Subject line you insert
in the recipe, does the problem go away?  It does here.  But then I
wonder whether this problem only happens in Gnus with the very first
or the very last line of the summary buffer.  If that's not so, I'm
probably missing something else.

> Do you still want the output of trace-redisplay?

No, I can do that myself now.

Thanks.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 43835 <at> debbugs.gnu.org
Subject: Re: bug#43835: 28.0.50; auto-hscroll-mode/current-line +
 show-paren-mode + gnus-summary-mode = bug
Date: Thu, 08 Oct 2020 10:39:38 +0200

On Thu, 08 Oct 2020 11:22:38 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: 43835 <at> debbugs.gnu.org
>> Date: Wed, 07 Oct 2020 22:54:51 +0200
>>
>> 0. emacs -Q
>> 1. Evaluate the following sexp:
>>
>> (let ((buf (get-buffer-create "*test*")))
>>   (with-current-buffer buf
>>     (setq auto-hscroll-mode 'current-line
>> 	  truncate-lines t
>> 	  bidi-paragraph-direction 'left-to-right)
>>     (insert "Subject: Re: bug#39280: 27.0.60; wdired-get-filename ignores first argument (this is a test)\n")
>>     (goto-char (point-min)))
>>   (show-paren-mode)
>>   (switch-to-buffer buf))
>>
>> 2. Now typing `C-e' shows the problem.
>
> bidi-paragraph-direction is set to left-to-right in any descendant of
> prog-mode, in particular in Emacs Lisp mode.  And yet I couldn't
> reproduce this in a Lisp buffer, no matter what I tried.  So that
> setting is not the only cause.

Strange, because when I replace the above sexp in step 1 by the
following, I see the same problem at step 2:

(let ((buf (get-buffer-create "*test*")))
  (with-current-buffer buf
    (setq auto-hscroll-mode 'current-line
	  truncate-lines t
	  bidi-paragraph-direction 'left-to-right)
    (insert "Subject: Re: bug#39280: 27.0.60; wdired-get-filename ignores first argument (this is a test)\n")
    (emacs-lisp-mode)
    (goto-char (point-min)))
  (show-paren-mode)
  (switch-to-buffer buf))

> If you add a line of text before and after the Subject line you insert
> in the recipe, does the problem go away?  It does here.  But then I
> wonder whether this problem only happens in Gnus with the very first
> or the very last line of the summary buffer.  If that's not so, I'm
> probably missing something else.

I think I've only seen this on the last line in a Gnus summary buffer.
This also holds for the new test case (also in Emacs Lisp mode): after
evaluating the following sexp, I see the problem only on the last line:

(let ((buf (get-buffer-create "*test*")))
  (with-current-buffer buf
    (setq auto-hscroll-mode 'current-line
	  truncate-lines t
	  bidi-paragraph-direction 'left-to-right)
    (insert "Subject: Re: bug#39280: 27.0.60; wdired-get-filename ignores first argument (this is a test)\nSubject: Re: bug#39280: 27.0.60; wdired-get-filename ignores first argument (this is a test)\nSubject: Re: bug#39280: 27.0.60; wdired-get-filename ignores first argument (this is a test)\n")
    (emacs-lisp-mode)
    (goto-char (point-min)))
  (show-paren-mode)
  (switch-to-buffer buf))

Steve Berman

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 43835 <at> debbugs.gnu.org
Subject: Re: bug#43835: 28.0.50; auto-hscroll-mode/current-line +
 show-paren-mode + gnus-summary-mode = bug
Date: Thu, 08 Oct 2020 12:10:15 +0300

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: 43835 <at> debbugs.gnu.org
> Date: Thu, 08 Oct 2020 10:39:38 +0200
> 
> > bidi-paragraph-direction is set to left-to-right in any descendant of
> > prog-mode, in particular in Emacs Lisp mode.  And yet I couldn't
> > reproduce this in a Lisp buffer, no matter what I tried.  So that
> > setting is not the only cause.
> 
> Strange, because when I replace the above sexp in step 1 by the
> following, I see the same problem at step 2:

I tried reproducing the problem in a real-life .el file, not in a
synthetic example with a single Lisp line.  That's why I said
bidi-paragraph-direction cannot be the only reason.

> > If you add a line of text before and after the Subject line you insert
> > in the recipe, does the problem go away?  It does here.  But then I
> > wonder whether this problem only happens in Gnus with the very first
> > or the very last line of the summary buffer.  If that's not so, I'm
> > probably missing something else.
> 
> I think I've only seen this on the last line in a Gnus summary buffer.
> This also holds for the new test case (also in Emacs Lisp mode): after
> evaluating the following sexp, I see the problem only on the last line:

OK, so I think the conditions for triggering the problem are well
understood, and we both have the same observations, thanks.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 43835 <at> debbugs.gnu.org
Subject: Re: bug#43835: 28.0.50; auto-hscroll-mode/current-line +
 show-paren-mode + gnus-summary-mode = bug
Date: Thu, 08 Oct 2020 12:18:55 +0200

On Thu, 08 Oct 2020 12:10:15 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: 43835 <at> debbugs.gnu.org
>> Date: Thu, 08 Oct 2020 10:39:38 +0200
>>
>> > bidi-paragraph-direction is set to left-to-right in any descendant of
>> > prog-mode, in particular in Emacs Lisp mode.  And yet I couldn't
>> > reproduce this in a Lisp buffer, no matter what I tried.  So that
>> > setting is not the only cause.
>>
>> Strange, because when I replace the above sexp in step 1 by the
>> following, I see the same problem at step 2:
>
> I tried reproducing the problem in a real-life .el file, not in a
> synthetic example with a single Lisp line.

I can see the problem is a real .el file, but it seems to depend on the
form of the line and other conditions I don't understand.  I visited
bindings.el and added the following line (with no line break, in case
one gets added to it in the email) at the end of the file:

(setq bla "Subject: Re: bug#39280: 27.0.60; wdired-get-filename ignores first argument")

Then I added a newline, evaluated (setq auto-hscroll-mode 'current-line
truncate-lines t) and enabled show-paren-mode.  With point at the
beginning of the above line I typed `C-e' and the line scrolled left and
the end of the line remained visible, i.e., no problem.  Then I deleted
the final `)', typed `C-a C-e' and the line scrolled left and then
immediately undid the hscroll so the end of the line was not visible but
after a fraction of a second it scrolled left again and the end of the
line remained visible.  Then I additionally deleted the final `"', typed
`C-a C-e' and the line scrolled left and now the end of the line
remained out of view indefinitely.  This even though the final line does
now does not end with a parenthesis group, in contrast to all previous
cases where I've seen the problem.  And indeed, if I restart the
experiment in a fresh emacs -Q and insert just `(setq bla "Subject: Re:
bug#39280: 27.0.60; wdired-get-filename ignores first argument' --
i.e. without the closing `")' -- plus a newline and make the other
necessary settings, then I see no hscrolling problem.  Can you replicate
these observations?

Steve Berman

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: stephen.berman <at> gmx.net
Cc: 43835 <at> debbugs.gnu.org
Subject: Re: bug#43835: 28.0.50;
 auto-hscroll-mode/current-line + show-paren-mode + gnus-summary-mode
 = bug
Date: Thu, 08 Oct 2020 14:53:12 +0300

> Date: Thu, 08 Oct 2020 12:10:15 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 43835 <at> debbugs.gnu.org
> 
> OK, so I think the conditions for triggering the problem are well
> understood, and we both have the same observations, thanks.

Should be fixed now on the emacs-27 branch, I think.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 43835 <at> debbugs.gnu.org
Subject: Re: bug#43835: 28.0.50; auto-hscroll-mode/current-line +
 show-paren-mode + gnus-summary-mode = bug
Date: Thu, 08 Oct 2020 14:55:58 +0300

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: 43835 <at> debbugs.gnu.org
> Date: Thu, 08 Oct 2020 12:18:55 +0200
> 
> I can see the problem is a real .el file, but it seems to depend on the
> form of the line and other conditions I don't understand.  I visited
> bindings.el and added the following line (with no line break, in case
> one gets added to it in the email) at the end of the file:

Like I said: this happens when the problematic line is either the very
first or the very last line of the buffer.  I think you are describing
the latter situation?

> (setq bla "Subject: Re: bug#39280: 27.0.60; wdired-get-filename ignores first argument")
> 
> Then I added a newline, evaluated (setq auto-hscroll-mode 'current-line
> truncate-lines t) and enabled show-paren-mode.  With point at the
> beginning of the above line I typed `C-e' and the line scrolled left and
> the end of the line remained visible, i.e., no problem.  Then I deleted
> the final `)', typed `C-a C-e' and the line scrolled left and then
> immediately undid the hscroll so the end of the line was not visible but
> after a fraction of a second it scrolled left again and the end of the
> line remained visible.  Then I additionally deleted the final `"', typed
> `C-a C-e' and the line scrolled left and now the end of the line
> remained out of view indefinitely.  This even though the final line does
> now does not end with a parenthesis group, in contrast to all previous
> cases where I've seen the problem.  And indeed, if I restart the
> experiment in a fresh emacs -Q and insert just `(setq bla "Subject: Re:
> bug#39280: 27.0.60; wdired-get-filename ignores first argument' --
> i.e. without the closing `")' -- plus a newline and make the other
> necessary settings, then I see no hscrolling problem.  Can you replicate
> these observations?

I don't see them after fixing the problem.  Is it still necessary to
see if they existed before the fix?

Thanks.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 43835 <at> debbugs.gnu.org
Subject: Re: bug#43835: 28.0.50; auto-hscroll-mode/current-line +
 show-paren-mode + gnus-summary-mode = bug
Date: Thu, 08 Oct 2020 14:24:17 +0200

On Thu, 08 Oct 2020 14:55:58 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: 43835 <at> debbugs.gnu.org
>> Date: Thu, 08 Oct 2020 12:18:55 +0200
>>
>> I can see the problem is a real .el file, but it seems to depend on the
>> form of the line and other conditions I don't understand.  I visited
>> bindings.el and added the following line (with no line break, in case
>> one gets added to it in the email) at the end of the file:
>
> Like I said: this happens when the problematic line is either the very
> first or the very last line of the buffer.  I think you are describing
> the latter situation?

Yes (that is, the last nonempty line -- but I have not seen the problem
on the first line if there are nonempty lines below it, nor if there is
more than one empty line at the end).

>> (setq bla "Subject: Re: bug#39280: 27.0.60; wdired-get-filename ignores
>> first argument")
>>
>> Then I added a newline, evaluated (setq auto-hscroll-mode 'current-line
>> truncate-lines t) and enabled show-paren-mode.  With point at the
>> beginning of the above line I typed `C-e' and the line scrolled left and
>> the end of the line remained visible, i.e., no problem.  Then I deleted
>> the final `)', typed `C-a C-e' and the line scrolled left and then
>> immediately undid the hscroll so the end of the line was not visible but
>> after a fraction of a second it scrolled left again and the end of the
>> line remained visible.  Then I additionally deleted the final `"', typed
>> `C-a C-e' and the line scrolled left and now the end of the line
>> remained out of view indefinitely.  This even though the final line does
>> now does not end with a parenthesis group, in contrast to all previous
>> cases where I've seen the problem.  And indeed, if I restart the
>> experiment in a fresh emacs -Q and insert just `(setq bla "Subject: Re:
>> bug#39280: 27.0.60; wdired-get-filename ignores first argument' --
>> i.e. without the closing `")' -- plus a newline and make the other
>> necessary settings, then I see no hscrolling problem.  Can you replicate
>> these observations?
>
> I don't see them after fixing the problem.  Is it still necessary to
> see if they existed before the fix?

No, with your fix all the test cases I've tried now show the correct
behavior.

On Thu, 08 Oct 2020 14:53:12 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> Date: Thu, 08 Oct 2020 12:10:15 +0300
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> Cc: 43835 <at> debbugs.gnu.org
>>
>> OK, so I think the conditions for triggering the problem are well
>> understood, and we both have the same observations, thanks.
>
> Should be fixed now on the emacs-27 branch, I think.

Confirmed, and many thanks!  Feel free to close the bug.

Steve Berman

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 43835-done <at> debbugs.gnu.org
Subject: Re: bug#43835: 28.0.50; auto-hscroll-mode/current-line +
 show-paren-mode + gnus-summary-mode = bug
Date: Thu, 08 Oct 2020 15:27:06 +0300

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: 43835 <at> debbugs.gnu.org
> Date: Thu, 08 Oct 2020 14:24:17 +0200
> 
> > Should be fixed now on the emacs-27 branch, I think.
> 
> Confirmed, and many thanks!  Feel free to close the bug.

Thanks, closing.

Previous Next

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