From unknown Mon Jun 16 23:44:10 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#59727 <59727@debbugs.gnu.org> To: bug#59727 <59727@debbugs.gnu.org> Subject: Status: Problems with displaying long lines Reply-To: bug#59727 <59727@debbugs.gnu.org> Date: Tue, 17 Jun 2025 06:44:10 +0000 retitle 59727 Problems with displaying long lines reassign 59727 emacs submitter 59727 Juri Linkov severity 59727 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 30 12:49:44 2022 Received: (at submit) by debbugs.gnu.org; 30 Nov 2022 17:49:44 +0000 Received: from localhost ([127.0.0.1]:34134 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0RDL-0001Wl-VK for submit@debbugs.gnu.org; Wed, 30 Nov 2022 12:49:44 -0500 Received: from lists.gnu.org ([209.51.188.17]:38610) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0RDJ-0001Wf-DX for submit@debbugs.gnu.org; Wed, 30 Nov 2022 12:49:43 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p0RDI-0004AJ-6i for bug-gnu-emacs@gnu.org; Wed, 30 Nov 2022 12:49:41 -0500 Received: from relay1-d.mail.gandi.net ([217.70.183.193]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p0RDF-0004WR-Pg for bug-gnu-emacs@gnu.org; Wed, 30 Nov 2022 12:49:39 -0500 Received: (Authenticated sender: juri@linkov.net) by mail.gandi.net (Postfix) with ESMTPSA id D336C240003 for ; Wed, 30 Nov 2022 17:49:32 +0000 (UTC) From: Juri Linkov To: bug-gnu-emacs@gnu.org Subject: Problems with displaying long lines Organization: LINKOV.NET Date: Wed, 30 Nov 2022 19:46:37 +0200 Message-ID: <86zgc8e3nm.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=217.70.183.193; envelope-from=juri@linkov.net; helo=relay1-d.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) [A new bug report from bug#56682] >> 1. after 'M-g TAB' (move-to-column) to 214748364 or more, >> the display is not updated anymore: moving point to the left >> from this position shows the cursor, moving point to the right >> has no visible effect. Is it a hard limit in the display engine? >> Its hex value is #xccccccc. > > Sounds like a possible bug. Does point move? What does "C-x =" say about > point if you move beyond column 214748364? Point moves correctly: point=214748362 of 1135341900 (19%) column=214748361 Hscroll=214748321 point=214748363 of 1135341900 (19%) column=214748362 Hscroll=214748322 point=214748364 of 1135341900 (19%) column=214748363 Hscroll=214748323 point=214748365 of 1135341900 (19%) column=214748364 Hscroll=214748324 point=214748366 of 1135341900 (19%) column=214748365 Hscroll=214748325 but the cursor motion is not visible. > If you window is auto-hscrolled as result, then there is indeed hard limit: > the X coordinate of a screen line is an 'int', so MAX_INT divided by the > pixel-width of your default font is as far as we can go. Maybe this limitation of auto-hscrolling should be documented? >> 2. after starting Isearch at a large column number, >> Emacs hangs up indefinitely, e.g. with >> 'M-g TAB 10000000 RET C-s' then even C-g doesn't get out. >> Debugging shows that the problem is in 'isearch-update' >> where the call to 'pos-visible-in-window-group-p' doesn't return. >> When this call is removed, the search is instantaneous. >> (Optimizing lazy-highlight is a separate problem in bug#56815.) > > I thought we agreed that calling pos-visible-in-window-p is not a good idea > in this situation, since it will always think any position is visible? Does pos-visible-in-window-p fail only on long lines? >> PS: it seems these problems are not related to the locked narrowing, >> rather the locked narrowing helped to expose them, so maybe they >> should be reported in a new separate bug report? > > It is unrelated, because handling lines that are both very long and > truncated on display uses a separate set of display shortcuts, and locked > narrowing has almost no effect on that. Ok, therefore a new bug report. From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 30 12:56:16 2022 Received: (at 59727) by debbugs.gnu.org; 30 Nov 2022 17:56:16 +0000 Received: from localhost ([127.0.0.1]:34163 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0RJf-0001aD-T8 for submit@debbugs.gnu.org; Wed, 30 Nov 2022 12:56:16 -0500 Received: from eggs.gnu.org ([209.51.188.92]:47686) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0RJc-0001a6-HY for 59727@debbugs.gnu.org; Wed, 30 Nov 2022 12:56:15 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p0RJW-000669-UF; Wed, 30 Nov 2022 12:56:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=T+ZQV6+/dXDnsTgXIfuLNrj4HnoZ7rjofdG1oEd1TzE=; b=ciWWa/tYOOaW jCiLFYn4hJ/ViRGQ+/11vZtBTb+jnC4o47NtjrQ8OXrDWRn/tMXoVxdxCas7Bo8jN6RPJxmqwOJEz fSUTlUU9cjMwPg6lnrhDnFcudJ4YPRwis2Q93R7JGU4vS2MmbupOPpv5ew+fWyVfD+UUOuoyDK5MX EKmTxSVqLeMjewCc2NGkfrey3X+EkFPqyHsUGHkGDQ70LhCZRKwiMrufflApindJAdfxG9U80VuD+ LUsz6jokP0IPgy0/HDlJkNWkXZ5tXnS9ubYAt/cQBgvXLoWqa4pSp3bEhDr+htT1M31orxXmHHug7 tC+SmTnDiaAFNIIz2MLscA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p0RJW-0005il-Dj; Wed, 30 Nov 2022 12:56:06 -0500 Date: Wed, 30 Nov 2022 19:55:36 +0200 Message-Id: <837czcjpif.fsf@gnu.org> From: Eli Zaretskii To: Juri Linkov In-Reply-To: <86zgc8e3nm.fsf@mail.linkov.net> (message from Juri Linkov on Wed, 30 Nov 2022 19:46:37 +0200) Subject: Re: bug#59727: Problems with displaying long lines References: <86zgc8e3nm.fsf@mail.linkov.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59727 Cc: 59727@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Juri Linkov > Date: Wed, 30 Nov 2022 19:46:37 +0200 > > [A new bug report from bug#56682] > > >> 1. after 'M-g TAB' (move-to-column) to 214748364 or more, > >> the display is not updated anymore: moving point to the left > >> from this position shows the cursor, moving point to the right > >> has no visible effect. Is it a hard limit in the display engine? > >> Its hex value is #xccccccc. > > > > Sounds like a possible bug. Does point move? What does "C-x =" say about > > point if you move beyond column 214748364? > > Point moves correctly: OK, then the new shortcuts in Emacs 29 for moving by columns in very long and truncated lines do work reasonably. > but the cursor motion is not visible. > > > If you window is auto-hscrolled as result, then there is indeed hard limit: > > the X coordinate of a screen line is an 'int', so MAX_INT divided by the > > pixel-width of your default font is as far as we can go. > > Maybe this limitation of auto-hscrolling should be documented? We could document them, indeed. But where? maybe in PROBLEMS? > >> 2. after starting Isearch at a large column number, > >> Emacs hangs up indefinitely, e.g. with > >> 'M-g TAB 10000000 RET C-s' then even C-g doesn't get out. > >> Debugging shows that the problem is in 'isearch-update' > >> where the call to 'pos-visible-in-window-group-p' doesn't return. > >> When this call is removed, the search is instantaneous. > >> (Optimizing lazy-highlight is a separate problem in bug#56815.) > > > > I thought we agreed that calling pos-visible-in-window-p is not a good idea > > in this situation, since it will always think any position is visible? > > Does pos-visible-in-window-p fail only on long lines? Not long, truncated ones. It doesn't understand that positions that are to the left or to the right of the viewport are not "visible". From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 30 13:14:02 2022 Received: (at 59727) by debbugs.gnu.org; 30 Nov 2022 18:14:02 +0000 Received: from localhost ([127.0.0.1]:34258 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0Rar-0001lW-V9 for submit@debbugs.gnu.org; Wed, 30 Nov 2022 13:14:02 -0500 Received: from relay11.mail.gandi.net ([217.70.178.231]:44411) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0Raq-0001lB-6o for 59727@debbugs.gnu.org; Wed, 30 Nov 2022 13:14:00 -0500 Received: (Authenticated sender: juri@linkov.net) by mail.gandi.net (Postfix) with ESMTPSA id F29B2100002; Wed, 30 Nov 2022 18:13:50 +0000 (UTC) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#59727: Problems with displaying long lines In-Reply-To: <837czcjpif.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 30 Nov 2022 19:55:36 +0200") Organization: LINKOV.NET References: <86zgc8e3nm.fsf@mail.linkov.net> <837czcjpif.fsf@gnu.org> Date: Wed, 30 Nov 2022 20:11:14 +0200 Message-ID: <86sfi0cny5.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 59727 Cc: 59727@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> but the cursor motion is not visible. >> >> > If you window is auto-hscrolled as result, then there is indeed hard limit: >> > the X coordinate of a screen line is an 'int', so MAX_INT divided by the >> > pixel-width of your default font is as far as we can go. >> >> Maybe this limitation of auto-hscrolling should be documented? > > We could document them, indeed. But where? maybe in PROBLEMS? Not sure how to document this limitation because it still works to some extent: when lines are not truncated, and point can be moved to the end of a 1 GB buffer, then after toggling line truncation while point is at the end of the buffer, cursor motion is shown correctly with auto-hscrolling near the end of the buffer. >> >> 2. after starting Isearch at a large column number, >> >> Emacs hangs up indefinitely, e.g. with >> >> 'M-g TAB 10000000 RET C-s' then even C-g doesn't get out. >> >> Debugging shows that the problem is in 'isearch-update' >> >> where the call to 'pos-visible-in-window-group-p' doesn't return. >> >> When this call is removed, the search is instantaneous. >> >> (Optimizing lazy-highlight is a separate problem in bug#56815.) >> > >> > I thought we agreed that calling pos-visible-in-window-p is not a good idea >> > in this situation, since it will always think any position is visible? >> >> Does pos-visible-in-window-p fail only on long lines? > > Not long, truncated ones. It doesn't understand that positions that are to > the left or to the right of the viewport are not "visible". I don't know how it works but the docstring of pos-visible-in-window-p says: If POS is only out of view because of horizontal scrolling, return non-nil. From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 30 13:17:53 2022 Received: (at 59727) by debbugs.gnu.org; 30 Nov 2022 18:17:53 +0000 Received: from localhost ([127.0.0.1]:34281 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0Reb-0001oD-1m for submit@debbugs.gnu.org; Wed, 30 Nov 2022 13:17:53 -0500 Received: from eggs.gnu.org ([209.51.188.92]:51518) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0ReZ-0001o6-8N for 59727@debbugs.gnu.org; Wed, 30 Nov 2022 13:17:52 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p0ReU-0001Xu-27; Wed, 30 Nov 2022 13:17:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=j3ZJf+8LVD3f/I0IfYAaLsYLjxh3K37rLfFt1wALHNw=; b=qeGBJ2cKD0aI Y6G8woPklDkRw635ZYKmXUjep1JOwPQg4pG59c12MPMGnoP2ptIsudElIF0op9NdjjNQEG7WK3dPs NMy9HxaT0b6T89VLcmRjXLh5+o79YoftcW7OKGCA8HCMUpFYYTz6RuQ7fwBn1el1H3nYOpZnm16ce fVr3VgU/vkTyOTvaf28efjlH0K6eeboSOP/moi5ggfLNtafanhZOKfViopDE0sVTMQus78OCkZZEj KNFYb7mIJXguWmVVu5lWOUXR1f3YpirYy0VzDHWGSxiHi2B3Pkha3uWfA2rj6nZbvM2roCjvBtIUx d9lwJX+bhUij7oBxNm0BdA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p0ReP-0006cd-I8; Wed, 30 Nov 2022 13:17:41 -0500 Date: Wed, 30 Nov 2022 20:17:13 +0200 Message-Id: <834jugjoie.fsf@gnu.org> From: Eli Zaretskii To: juri@linkov.net In-Reply-To: <837czcjpif.fsf@gnu.org> (message from Eli Zaretskii on Wed, 30 Nov 2022 19:55:36 +0200) Subject: Re: bug#59727: Problems with displaying long lines References: <86zgc8e3nm.fsf@mail.linkov.net> <837czcjpif.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59727 Cc: 59727@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 59727@debbugs.gnu.org > Date: Wed, 30 Nov 2022 19:55:36 +0200 > From: Eli Zaretskii > > > > the X coordinate of a screen line is an 'int', so MAX_INT divided by the > > > pixel-width of your default font is as far as we can go. > > > > Maybe this limitation of auto-hscrolling should be documented? > > We could document them, indeed. But where? maybe in PROBLEMS? Or we could bite the bullet and lift the restriction: make current_x be a ptrdiff_t, and then audit all the gazillion places where we make calculations with the X coordinate and make sure we use ptrdiff_t there. Probably not for emacs-29. From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 30 13:38:54 2022 Received: (at 59727) by debbugs.gnu.org; 30 Nov 2022 18:38:55 +0000 Received: from localhost ([127.0.0.1]:34402 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0Ryw-00021T-Ks for submit@debbugs.gnu.org; Wed, 30 Nov 2022 13:38:54 -0500 Received: from eggs.gnu.org ([209.51.188.92]:50970) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0Rys-00021N-I9 for 59727@debbugs.gnu.org; Wed, 30 Nov 2022 13:38:53 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p0Rym-00064s-6V; Wed, 30 Nov 2022 13:38:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=AvFNDNv5/W9nCI7swbjLtHx3FA4IarhoqmuTIYFlZ+I=; b=bufyYlNGOtFA TTVIJlRN0x5tulN37ON0/Rki8b5xreAxsilQpCqY/GnZey1Zwihz5wuQ9QlRMI4V33Pch7Rzn5yJU WGhRs0v4j0QLASz8tIKVAson0UuDqP7+cH7DaJ6hq6I/uQxmqqgFbk9wflxB++m8NpLpnYFkvBkds ok9IwsV1XIQaW2uVJzVZlFwWK8Cg+MG1JxsCS1Rw4aEmzXxbFytmrBCP58triCPb/8/tGE8wKM00S mvbDOer9MOAPbjkdM2nyz6S8FoIcleDMz2prqvZ/vkA9DYmXKwTnbWa8nTzAdPmiwfNdysZof05ya eY7QkdoMhtc12cCrnolfGA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p0Ryl-0004Rd-MU; Wed, 30 Nov 2022 13:38:44 -0500 Date: Wed, 30 Nov 2022 20:38:14 +0200 Message-Id: <831qpkjnjd.fsf@gnu.org> From: Eli Zaretskii To: Juri Linkov In-Reply-To: <86sfi0cny5.fsf@mail.linkov.net> (message from Juri Linkov on Wed, 30 Nov 2022 20:11:14 +0200) Subject: Re: bug#59727: Problems with displaying long lines References: <86zgc8e3nm.fsf@mail.linkov.net> <837czcjpif.fsf@gnu.org> <86sfi0cny5.fsf@mail.linkov.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59727 Cc: 59727@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Juri Linkov > Cc: 59727@debbugs.gnu.org > Date: Wed, 30 Nov 2022 20:11:14 +0200 > > >> Does pos-visible-in-window-p fail only on long lines? > > > > Not long, truncated ones. It doesn't understand that positions that are to > > the left or to the right of the viewport are not "visible". > > I don't know how it works but the docstring of pos-visible-in-window-p > says: > > If POS is only out of view because of horizontal scrolling, return non-nil. That's what I said, no?