From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#68786: 30.0.50; Horizontal overscroll Date: Mon, 29 Jan 2024 14:02:08 +0200 Message-ID: <86msso4abj.fsf@gnu.org> References: <871qa1b08i.fsf@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29485"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 68786@debbugs.gnu.org To: Andrey Listopadov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jan 29 13:03:22 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rUQME-0007SN-EB for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 29 Jan 2024 13:03:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rUQLp-0002fi-M3; Mon, 29 Jan 2024 07:02:57 -0500 Original-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 1rUQLm-0002dc-8N for bug-gnu-emacs@gnu.org; Mon, 29 Jan 2024 07:02:54 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rUQLl-0008JF-VO for bug-gnu-emacs@gnu.org; Mon, 29 Jan 2024 07:02:53 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rUQLu-0004CM-2S for bug-gnu-emacs@gnu.org; Mon, 29 Jan 2024 07:03:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 29 Jan 2024 12:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68786 X-GNU-PR-Package: emacs Original-Received: via spool by 68786-submit@debbugs.gnu.org id=B68786.170652974716091 (code B ref 68786); Mon, 29 Jan 2024 12:03:02 +0000 Original-Received: (at 68786) by debbugs.gnu.org; 29 Jan 2024 12:02:27 +0000 Original-Received: from localhost ([127.0.0.1]:59191 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rUQLL-0004BS-AR for submit@debbugs.gnu.org; Mon, 29 Jan 2024 07:02:27 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51250) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rUQLJ-0004BF-MG for 68786@debbugs.gnu.org; Mon, 29 Jan 2024 07:02:26 -0500 Original-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 1rUQL6-0008Cb-2p; Mon, 29 Jan 2024 07:02:12 -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=Yywf+k61JvmWRj0ekfXJ3lBpyAfrq7ie808Pu2szOKQ=; b=L3cqOLiHL2eC R2EyLEfgo/EcUN/fUvkAI/tvCwTnz5cYFrt52RL1pLgcNwmtKT7zFvZkhHUKor5FqtDg2NWn/H+V8 ADN/+IkyyXNGwVWxczuypeBtIB+AIpF2RjaucDDnB+QQGqVdyrw8Z1qWfxBEGG8HMs6p7FI2JevC+ seUH9j32Reya1xUbCroWMSj6l1ogQ1GpZ7MPUJ819DM7ggoD0cSnMKGX8K2WXsTa7xXRkerXmDnOe 5ZX2Wv+10vQanPjnE4GwGtRFCds7R19ornzIAOl1RaNqhA052Iw+z6v8rMQz1085kYTa0kJW4Ruiu /KM0YRle0O5yTwrinGqHWw==; In-Reply-To: <871qa1b08i.fsf@gmail.com> (message from Andrey Listopadov on Sun, 28 Jan 2024 23:41:57 +0300) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:279123 Archived-At: > From: Andrey Listopadov > Date: Sun, 28 Jan 2024 23:41:57 +0300 > > However, when scrolling to the right with the touchpad (to avoid > confusion view goes to the right and the text goes to the left), we can > do this: > > |_____________Emacs____________| > |ation. | > |ts buffer. | > | | > | | > | | > |______________________________| > |-------------------------=====| > |______________________________| > > The scrollbar itself doesn't allow us to go beyond the longest text > visible text. Scrolling with the touchpad, however, allows for this. > We can even do this: > > |_____________Emacs____________| > | | > | | > | | > | | > | | > |______________________________| > |----------------------------==| > |______________________________| > > Or even this: > > |_____________Emacs____________| > | | > | | > | | > | | > | | > |______________________________| > |-----------------------------=| > |______________________________| > > The text is so far left, that the draggable portion of the scrollbar no > longer shrinks. The above can also be done with horizontal scroll bar, if instead of dragging the scroll-bar's "thumb" you click on the arrow at the right side of the scroll bar. At least it works here (perhaps this depends on the toolkit, I don't know). So I think the inconsistency is much smaller than you think, and we should stop right here and talk about why this makes you uncomfortable or requires any changes in your opinion. I personally find nothing bad or unexpected with the ability to scroll past the last visible character: after all, if the user doesn't want that, he/she can avoid scrolling farther than he/she wants. It is true that most other applications don't vary the thumb size, but Emacs has always behaved like it does, so changing it to follow the other apps is not an option at this point, at least not by default. Having said that, ... > I would like to ask for a feature to limit the horizontal scroll by the > longest line, much like the horizontal scrollbar works by default. It > may not be the longest line in the buffer, as calculating this for huge > buffers is probably too impactful unless we can cache the longest line > length until the buffer is changed. Or maybe Emacs already knows the > buffer's "dimensions", I don't know. ... I won't object to such a feature, provided that it's optional and OFF by default, and also that it is supported on as many toolkits as is practical. Patches welcome.