From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE, MAILING_LIST_MULTI,TRACKER_ID autolearn=no autolearn_force=no version=3.4.4 Received: from tb-ob1.topicbox.com (tb-ob1.topicbox.com [64.147.108.173]) by inbox.vuxu.org (Postfix) with ESMTP id 059C02D1A8 for ; Mon, 30 Sep 2024 17:56:35 +0200 (CEST) Received: from tb-mx1.topicbox.com (tb-mx1.nyi.icgroup.com [10.90.30.61]) by tb-ob1.topicbox.com (Postfix) with ESMTP id AE44A2F943 for ; Mon, 30 Sep 2024 11:56:34 -0400 (EDT) (envelope-from bounce.mM94ca138b9ac4a4b4f9bafb2f.r522be890-2105-11eb-b15e-8d699134e1fa@9fans.bounce.topicbox.com) Received: by tb-mx1.topicbox.com (Postfix, from userid 1132) id A47D9233AF7B; Mon, 30 Sep 2024 11:56:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=9fans.net; h=from:to :message-id:date:mime-version:content-type :content-transfer-encoding:list-help:list-id:list-post :list-subscribe:reply-to:subject:list-unsubscribe; s=dkim-1; t= 1727711794; x=1727798194; bh=vj9XbC/CDcTT5cIJLJjOjn5lQcXjCB0zkMF w8eHDahI=; b=FPQbjdxN1MFjo5pcd0TUIlvb7ptWTI3vMpMLbUjrUEtvGJANTuK ubc2LMo9gd6xG5gjo0ZEBg0s6KO/fVbMMUDpN9rnHOP0mEW7NXcMNaQLgSAPHYtc AftZnqwNL+IvCNhh7vfoggtp6cUb56EBWbFbM7pOG8rKbAB3maEG//sA= From: kalterdev@gmail.com To: 9fans <9fans@9fans.net> Message-Id: <17277117780.5c53F.54435@composer.9fans.topicbox.com> Date: Mon, 30 Sep 2024 11:56:18 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=17277117781.3c12fc.54435 Content-Transfer-Encoding: 7bit Topicbox-Policy-Reasoning: allow: sender is a member Topicbox-Message-UUID: 87f745c2-7f44-11ef-aa0e-bad040decc0b Archived-At: =?UTF-8?B?PGh0dHBzOi8vOWZhbnMudG9waWNib3guY29tL2dyb3Vwcy85?= =?UTF-8?B?ZmFucy9UMDUzOWNhNmE5MWFkYWZhNi1NOTRjYTEzOGI5YWM0YTRiNGY5YmFm?= =?UTF-8?B?YjJmPg==?= List-Help: List-Id: "9fans" <9fans.9fans.net> List-Post: List-Software: Topicbox v0 List-Subscribe: Precedence: list Reply-To: 9fans <9fans@9fans.net> Subject: [9fans] Bug: Acme: Scrolling is not deterministic for long lines List-Unsubscribe: , Topicbox-Delivery-ID: 2:9fans:437d30aa-c441-11e9-8a57-d036212d11b0:522be890-2105-11eb-b15e-8d699134e1fa:M94ca138b9ac4a4b4f9bafb2f:1:EaFgJtKL9lnbP9XK6LoBPIlc7FHViJFHaUW-adlPl5w --17277117781.3c12fc.54435 Date: Mon, 30 Sep 2024 11:56:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Expected behavior When I scroll with button 3, the line next to the cursor always goes to the beginning of the visible area. Similarly, If the line is long and broken (wordwrapped) by Acme, clicking on the line's second part pushes it to the beginning of the visible area. Clicking button 1 on the same place must, and in most cases does, pull the line back to its original place. If the line is long and broken by Acme, though, button 1 must guarantee that the visible part of the line goes back. Unexpected behavior If the first visible line is long and broken by Acme, button 1 does not pull it's visible part to the cursor's location. Steps to reproduce the problem The problem typically occurs when Acme breaks long lines. Find a long line, make Acme break it, and scroll with buttons 3 and 1 on the line's first or second part. Another weird behavior is exhibited by the first visible line broken by Acme. Try to scroll it's second part with buttons 3 and 1. On button 1, the whole line goes to its original place except it's first character. See demo for visual demonstration of the two cases. https://i.imgur.com/S1dyDlU.mp4 Sometimes even the beginning of the long line does not return. I couldn't identify the exact cause, though, but there's a demo. https://i.imgur.com/kKNXKC1.mp4 plan9port version a2567fcac9851e5cc965a236679f568b0e79cff2 OS version macOS 14.5 (23F79) ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T0539ca6a91adafa6-M94ca1= 38b9ac4a4b4f9bafb2f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription --17277117781.3c12fc.54435 Date: Mon, 30 Sep 2024 11:56:18 -0400 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Expected behavior

=
When I scroll with button 3, the line next to the cursor always goes
to the beginning of the visible area. Similarly, If the line= is long
and broken (wordwrapped) by Acme, clicking on the = line's second part
pushes it to the beginning of the vi= sible area.

Clicking button 1 on the same = place must, and in most cases does, pull
the line back to i= ts original place. If the line is long and broken by
Acme, = though, button 1 must guarantee that the visible part of the
line goes back.

Unexpected behavior

If the first visible line is long and broken b= y Acme, button 1 does
not pull it's visible part to the= cursor's location.

Steps to reproduce= the problem

The problem typically occurs = when Acme breaks long lines. Find a long
line, make Acme br= eak it, and scroll with buttons 3 and 1 on the
line's f= irst or second part.

Another weird behavio= r is exhibited by the first visible line broken
by Acme. Tr= y to scroll it's second part with buttons 3 and 1. On
b= utton 1, the whole line goes to its original place except it's first
character.

See demo for visu= al demonstration of the two cases.


Sometimes even the beginning of the long lin= e does not return. I
couldn't identify the exact cause,= though, but there's a demo.


plan9port version

a2567fcac9851e5cc965a236679f568b0e79cff2

OS version

macOS 14.5 (23F79)
<= /div>

= --17277117781.3c12fc.54435--