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

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

[Stephen Berman]

[-- Attachment #1: Type: text/plain, Size: 3107 bytes --]

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


[-- Attachment #2: test --]
[-- Type: application/octet-stream, Size: 9912 bytes --]

From larsi@gnus.org Thu Oct  1 23:27:14 2020
Return-Path: <larsi@gnus.org>
Delivered-To: unknown
Received: from pop.gmx.net (212.227.17.169:995) by strobe-jhalfs.local with
  POP3-SSL; 01 Oct 2020 21:27:14 -0000
Received: from quimby.gnus.org ([95.216.78.240]) by mx-ha.gmx.net (mxgmx101
 [212.227.17.5]) with ESMTPS (Nemesis) id 1M4Juj-1kON510b1l-000I6W for
 <stephen.berman@gmx.net>; Thu, 01 Oct 2020 23:26:42 +0200
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
	 s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:
	References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:
	Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
	Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
	List-Subscribe:List-Post:List-Owner:List-Archive;
	bh=gv4ov3N0sPb/vqtZjxSD2wXj+xOEfXzqE3mGol5EVQQ=; b=eTHnRi+bEEtHLZIs5cJ+yy0X4m
	Y9l1ruJUUhelYYTjf7J6hWga2LnYEKZgH6Y/PIgn1Bw/2ZA9rxMngUZs57GGoG9e+psAgIWJE9QR+
	lQKxscS6ZQFHNM/OLGSUGekrpSQQ17l3M5gk4PjXhknRbKwYElud4z/wNJmdHbfSSI0U=;
Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo)
	by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <larsi@gnus.org>)
	id 1kO65u-0003bj-Dp; Thu, 01 Oct 2020 23:26:40 +0200
From: Lars Ingebrigtsen <larsi@gnus.org>
To: Stephen Berman <stephen.berman@gmx.net>
Cc: Tino Calancha <tino.calancha@gmail.com>,  39280@debbugs.gnu.org
Subject: Re: bug#39280: 27.0.60; wdired-get-filename ignores first argument (this is a test)
References: <87k15fpaj2.fsf@calancha-pc.dy.bbexcite.jp>
	<87tv4j1cjm.fsf@gmx.net>
	<alpine.DEB.2.21.2001252209420.20097@calancha-pc.dy.bbexcite.jp>
	<87ftg2v6j9.fsf@gmx.net>
X-Now-Playing: Joanna Newsom's _The Milk-Eyed Mender_: ""En Gallop""
Date: Thu, 01 Oct 2020 23:26:29 +0200
In-Reply-To: <87ftg2v6j9.fsf@gmx.net> (Stephen Berman's message of "Sun, 26
	Jan 2020 11:47:06 +0100")
Message-ID: <87lfgpzlh6.fsf@gnus.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 
 Content preview:  Stephen Berman <stephen.berman@gmx.net> writes: >>> Do you
    have a use case for this? >> No, I don't have one. > > I see you do now,
   as a possible fix for bug#39284. Looks like this wasn't applied at the time,
    but if I read the patch correctly, it looks like the right fix to me, so
   I've applied it to Emacs 28 now. 
 
 Content analysis details:   (-2.9 points, 5.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
                             [score: 0.0000]
Envelope-To: <stephen.berman@gmx.net>
X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=V3;
X-Spam-Flag: NO
X-UI-Filterresults: notjunk:1;V03:K0:ti+gBpEImdY=:hCeCOqElgHqOcifO5jncQpFgek
 ZSDg4MZfpw0Dknfao7k225snGBw5muR3xEXf34ChVLTVnMvP9GBdoTuBm7dMjl6UyY+ELMBFk
 zBYE7EjgoJATj8p0lbvpgnbS/wLUzIPM0DIfmTd2gpuoEtes+GzSHz53a+MbiDDDZgYW99B5A
 B+lNm7W8ophaBn9xRcXs16SIQ0WB+T9BX36t8hHg4BXc4eiCUkUK2WCU/hVJuUaQeeAH5wzRR
 MZh2vIa90TVFJBEU7FcftEw7hMMD6EgeGm+R2Uhcx1bYlT6NgTH0BLu/karNpn/lwSC7SyZt2
 A63Q5GQExtiZ8n0qLNTl3ZHsL03pF0YNbXYUsclp9vAj56soKfVNp8tQ44pU4c72rh5DHg3qC
 9ae0MC8UqU19lUwni3shbQbcYsk2cU4/o/2Q21u1gWgQXLp98OmzN0r28Y+i+k69HQwYtXkTf
 GworG68/G9Ek4QzAhLG1lxSZxXFVpR7tXn3j+1u+/jV8nu3UaNEZaMnNylAlx/jBomIifGDf1
 QSN2bD8YBFmEbCE9gVdP4SjcvSdSNLjeLS4DddXTPK9gb1t+xZwybu3MOZ76zSj0EWzf4ZCxi
 ThUb2GGGeEy0koaV4hThF+QI0Q/yNzOAFOf+0EU+YGGBocYBAzcj0yJsOGogrBjoL2TMQi6Jh
 oHl0NahGVSqA4w6A17X/aeMgbwWZlxhy7RkQ0uvVxUS3sHIxuQFGauqSXV/8semSVUxcptJmp
 lOYJrfjyDj4XGbIIVpdY3bw6N90bMoDuQW4zMeG+z8i8SuEavf0SYD4uu19krqEeOD1ZxSXYG
 7gn+6DYBfOQuUzzO7WHM003n2BQ3a3ny8Bh6aRNgA8zKZ32pvToxPIr1Deae9deYOjncCghcW
 cwyZYU/z6SzgK/cIDdywmIrbFTShxOb0rgC6LC4oePL2tCVNGaQ7ZiWLDa+GPUhAyGPBAtxKS
 mT4xfbwSfTNa8pF+ZCiG86MdgJ3jCuyn08IVrD6gwnOO+eBwVeBXwyszJt4KwcfYJSOFxyqsz
 fs7yMzBqieMYI2sUB/T5BlH2mm/yZXm+ErGDE5vgVggtLWM7UfNGEpcuZyw4XLEmcD6GHIWJh
 sZmqcZIt0iaioQblRUZnCe97pZ4+E7mtI7zDxiYQVnrnVCzMlLx/L+SBbZ/CB6O7kwnWcIz2z
 m6orWKsE4KOm9UVZ6I/D38SJ769TfYfy/XMqU5RkdeqtvnaWSOWCmP4WWOsFv1j6TpCAIS8xF
 UUL516TNLh4NyXAetSw41tQCg6JtGZkgvtlP91FzI79kNG28CQAtPx2C9LJMxRFzoXpy6e/aV
 SMnBJuQ8lA0305qfNVEerCeObfx5W2vP98Mp0PdYfDtF/ZnL2fmcxoupOQrfzbv8t+LqBGffm
 SHLv9ewynZdO0HJULXTtFcdhaUJbHv2PAwZE+UWh2vD6jdJj9DjvDnYpZeYEVqf72P/U657RL
 /Nxiwkd4O6Q5clP/TzZPepaqSpWf16Svhs2uDig/g3TaGGasgvlphM1fAIrSoWrxPkaWLNHDe
 MckuL3tUqC+V1hhzI4YMmDZG9/g3YfGq9QoBIsSJKeQPSUXrf6C0OO/ocPW5ER10QRsel5rhW
 i0XeAJhvuqb3Zws0ZL/xpU/iJ3XVuP0CZuhHJsUAPp3SqgT8O5/OEdeWihAHtiP6x5ZLnyl8s
 n3ctk8vs5zwY54Q1Ze+wnljK66B8QvJEGpzAAob5gDWM3oFUv2m8+nk1Lyvf4m42tyWqaP0JQ
 DD3zlgNd1iciR/V52w+vsnxtgc4mXg865vn85Uo3hfassuqyx6YNFR+IBGFNEEWqgczV+rR1F
 0kG+7qhRfTShfhblvnlzz03jXvNWgx6oXbRt8VvSL3VPcztcfvZy3074pUOermk0DeqsZq/yM
 GwmDhJ7gN/GYf8F7YyVhYpWeNC7Xv8l9arQIKhnpihX7BHhDX9OJVCnmaqsYf+nvQ8etryhU4
 N2IeA2XsJUPvlYl7Vmk3LWMuyjr0Kn5O+QDYtocktj22cvJ/wvVHydEr4MyeOxMkp8Y5LVdxp
 ucaiqx7OnDDWRSpqVaJYyAhfITMtLm4XPVsi713Ieol/ugTVGAhWZf5Z1ze2Xw4EA/vuNdDRM
 rBCopsI5qIW5UdWmKl4fAf1bFo5YOzQM+Ae54ZK1gj0owYmJLhuhQjXdkqkOaRKZTabCGua1h
 4X/vYaQMWQCTmOXEqUL8sgWLGG0z6LRCuer0p9TFEB0DElB/haj99Qnyw5/FKoxd84jMgZsJw
 7mLAWtWgEf6bCotTQjpA0NsgrOn07fZSiATarcbrOKUCEZHL7ILgcm40tPZYeb7SgSfm5Z+WA
 yY/FwrUb7JyvLMFbvGM9r/xPf43SN1ABgbz6ZUmTLC4ckl14ojC9lowGiErH/lFBBAF/8v8lI
 0onNQakVerLLqgJ5C2dVffMYUNCx8MfiqlEKEh9XOjdTecXpAeIPPrIm+7C3gmgLXSL4dqvWN
 FRNyERLPlf+pptIKP7uXF4WF7jCzAu04PJyt+1NcKqUoQZbDM27brknMyGrAJH6qv8Z1xZShc
 2w6KLz43c5QWglxnH896p27tAxd59E223D+rdXFy+LR9i8XabEzm4xDMewVNfZRZt+QqN2usR
 0pn2kXb/RKtjbgkE00mr8AxzKox/QFhBUEqWQM6EOpO0OtdS3s3BX0zArBpGTL31yA06Km3Gf
 dpDcP7rJBjrxfSMrOOaqZGaRAIhZWVxDeX4HPwRX+b5wIIJPgO6yVDe01oYYmXj5vqnSBYsCM
 T7eQMcYEaLw8HASrqeo3NNatg4lf+KoZfjAnNWtNG+1Vs5u9Xi9jdrrFFBT2SMxOaDbDCTbMw
 tCioTNV3oZDfJ/i+BUg1qKkt9tKVoLqXM2s+RM5JzCzllFuuUGpqvSks51ScLyyT+w+CSjvDC
 RMzfeHG0pQgX3H4gYoKeayb2QsqkZlJwv9esGgJeganiJMg9nN7hOpfiHVv3r/0/UsXCNySQm
 +NeehENQOdCL3y9UTMAG1wVGIq+w+ypulPY+6LMndpnpBUMUozQd1H0sjfiid8o+m39XF40hq
 6bwQ724rdfsg+cP5GQAOh3Css1uSfc1DyJn4es1/TTB5+X+Gfq1vUVKQulnJMq8tXdLLCEaON
 SGybiRA2dcBH15CLm7B4g1Y65Stvq8KET01CguJWzhBoIGd3TmfUPPqNxzBMxzx2R/xFob++m
 0MkVx5cJo3EBwaDivQTK9qY1EsRbDu1oPNpQ8DV5FH/9J/rRuI2/3RVeszC7PXBgBwqi8WW4+
 EYP3CQvOqH7mmHmubc4ZH+tI75D7bz/QvjZRiG+po1gVZnVf8PDRD5S2kUu6pqrls0+Etl9oU
 9ztrt9BudxJnP4driXsBQ93J6R5/RvM0u6Vo4sCh+gGre/PfI+8HUY4F0RiSM/BFGHbTpomVz
 3TdAEeMBQruaJdw1z1ILJxOQArqF4xovo4wTSJr0RuQzv6KsxCiEhXl76K42xHhc4SasaDPAE
 3Iwn+RMf0/y2rtSmhrOQoCpe/PcoUPI9soZB3et2PbtbXc9JqB7l9bICBjdvtIYpYrPlnN5+K
 OkgYNnRHnbkjhYf9HDtmnaBZswJxQ8H64afE7T5NN7eOhg5fXYs/iFcDxd7xAIf8hGYxLn/16
 VcchNvQEp2B1GQoF+MotCsyAXukc2xQxe8Yj0vQccHYn3MR6KROr6sJ1JLsYRBOpjm/vqCZLs
 J1HXR4/COe2oeuIt+XNHi8cLk3JZJ+sC6g9WsXxYBTGFezNXFwQkxTGekvAW3sOlk1WHqdRCy
 OA5L8f0zp1Jzd4Y52tjYF5BIczGn/gU0UPRiqalOpHUGvCc1iLgoyw8V7FY7+cH4Ry3xNETyw
 8xbOMS3xkvlqcqeKgJHFrDvoPW/GW47NvcHqzcCK1hRUwqF/InokDKIWu/rCB4eK8/56pb2ZY
 fFoV5puAfs/gASba88Cz/zs3XH3OPysotWa9G7n41tcF0PRO8f1t0zXlREK4nUY7ypTohv0ZG
 tQPI++d8WQ19KLTuzlZEnymZYzTz1bKJxHf2n9V61kQRdOh/NFx7xDJowMfTUmheLVukvXrP8
 CVmuWCiW99vrRul2iA/ip6V6EWpLYnpyQbTg8WOFz2Z+N9rcm+aW+aGAuwrHgj/xamux1vOWi
 EeBKhgNn/6x7K1Um5D1ErzHwRFRGWLTxzVOF4QvzDcCX+oe04PVYj4v8RZVu4uPW4PmxVddq9
 Da/lJXSQRgDSWIRoTbEPmAVeLAb5DdNzG9pRoGMvRzC9V+xg0z7JLmsyh77dhSBTguGNffSQi
 LzAuUwh0Fp9N6tzNA6p7Ysl1Fso553jwYoNNmkK6sUeSBpitlN+IIsLhxkNY2TFFQz66HAcJs
 vADtYEwyTZeYE8pydjgEGsmkhSFDYPqyiBrVE4aPnlAX7EWRAW29DP23eCjCNM4CIwQPzBtuS
 m8woNFAg04pvMRmJrE0qn9xk3sl7Q1ogsdqT8IRPrGOjGCK7eC42h+AqBMSZP3V0cOq3D1Kwi
 6p1jifwg89Px8D9hoEOXEMJnPasWeGzo+Oi8efwBGRFRJj2KViEJ809pzvzm2rHaSDRlGc6zT
 4JB8m4aoda29mLERJ+xvoq1sqDGl9xhPwXZNiNyKNAGxStdVxTvOYaetg5TBcHgMOpYnYWEtt
 OgLzAi9mok68+rgSmxJcO0lL3bLFPC6U0I+sZkHgOuVt045LajU0bI4JPuZVd2ZUdGkdOmjM5
 l/y1n+VTqK3h7fGXPo46afjNe3Bz4J+inZXBlGIGzzMkRhXl8EXAar7W3Xk0gK3mIrn92YGZD
 h9bTgLX+jfgzJZTrKcVm7dce02jy+jkdI+3oUCWS8VZ57Tbmtd9rCMw/3PZe4QKERI9Pd6q2t
 1NlwtnLRmHuFcq62L3Lt8YwXVoxNTYpBqdcDQCQnX/eV/CP0Bt2x2f/MUixXrKvI8cQtyybnb
 nibcxLCIWIm0ioLfofKMMPDzesaAq/6+erPwtMVRvg01zr+vVBg9aXqVmQ//Cir5EVUqWCBme
 RLhbjZ5/W0kVw+dYRw7MEILul0UuHWNvP4MPpf8fqCQUMMKDrsmMR/+SXd8Rq7L4dmcLNtfQV
 /zvqjeGUGKiPpeEYniNRRsWQXQLTXMrG0PN5EIKS/TDVLEk6Cggfi5sB/vF5oM7UEg+9gggDr
 JihoZApI0F5gR9rlT/RkFwPB5VOswusvSNJ09pX4ZCLf2NlGdMdqTlZLiEbsfAmni0bO1W/4x
 FGpQsEc0JlVWaQ4J6imTsNmI5YYis8uRlRlBJTl3hGWRdbzrT+ORBsHACNY8wzL1LqBpYycOL
 rYAyKrjg43SxBhcwUki4/q1SUcHDMGoDl8RFIjbiDDml6Z0M/TaC3A9v9o5LSbxefFkWqnT3l
 k/CuOVKNjqU45kRpE7TDcpxGZovVp9NW9+x23XRMnOoYipAOTwKYUbWqUPCqcp8e302zNxEGK
 7A1V5KiYurcXkyp2CfkthuBAnUdD0ndJ9Hq/6tLUcbXZN75S+pvkab/1bRv7E2KXuicPVD7Vw
 Cainkb1PwVImNlcSTZ4M+fnCIGBZ/T/5qx2AFqU8plETg2RI+R9R3/NnE3NVd/BQShJvtimfK
 YwRqLrji7rTeg4kxYWMqXcvOGSpBKfn5B9ci6JxTznNoxEBG0gQIEnlcnNNcHeaJpIyiRy+Yq
 faCo7oEel97UXNoN5Ho79iXCJKDM8yzIaFm9Nkmt9/q2V+xo0Gf3F/mC8H8vkxZERZcEPsqMR
 bZH0uF4aZTzEwB0N7KGt3Gty2nL38JZdswlcOrhK4C/91QqqL9MVztizEcoJOq8S97SAkvSNk
 /T+FUVB5zaIJYLOIve1fEZnHdbVHM+ckN1nUjXeCFGfQ1CMXUHsMUmV2mOL3nD0Ct86IqzHxZ
 4WtFMAdPIqlRHqPaw8/ev/22Zmfq8/gMqtkxyjGTtGGbAbBXptrHLzeUJyymMungYWwX7VCWj
 jY2/4aCJCZ1Lnnd85xKQK51R9CIdj4x/Dw0IHth3DQVFMFU=

Stephen Berman <stephen.berman@gmx.net> writes:

>>> Do you have a use case for this?
>> No, I don't have one.
>
> I see you do now, as a possible fix for bug#39284.

Looks like this wasn't applied at the time, but if I read the patch
correctly, it looks like the right fix to me, so I've applied it to
Emacs 28 now.

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

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

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@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.

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

[Stephen Berman]

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

>> From: Stephen Berman <stephen.berman@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

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

[Stephen Berman]

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

> On Tue, 06 Oct 2020 22:10:26 +0300 Eli Zaretskii <eliz@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

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

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 43835@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...

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

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 43835@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.

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

[Eli Zaretskii]

> Date: Wed, 07 Oct 2020 10:25:27 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 43835@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?

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

[Eli Zaretskii]

> Date: Wed, 07 Oct 2020 15:46:42 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 43835@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.

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

[Stephen Berman]

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

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: 43835@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

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

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 43835@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.

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

[Stephen Berman]

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

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: 43835@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

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

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 43835@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.

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

[Stephen Berman]

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

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: 43835@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

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

[Eli Zaretskii]

> Date: Thu, 08 Oct 2020 12:10:15 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 43835@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.

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

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 43835@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.

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

[Stephen Berman]

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

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: 43835@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@gnu.org> wrote:

>> Date: Thu, 08 Oct 2020 12:10:15 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: 43835@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

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

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 43835@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.