From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <9front-bounces@9front.inri.net> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from 9front.inri.net (9front.inri.net [168.235.81.73]) by inbox.vuxu.org (Postfix) with ESMTP id 2CFE524BDB for ; Tue, 29 Oct 2024 01:39:09 +0100 (CET) Received: from fhigh-a6-smtp.messagingengine.com ([103.168.172.157]) by 9front; Mon Oct 28 20:37:02 -0400 2024 Received: from phl-compute-07.internal (phl-compute-07.phl.internal [10.202.2.47]) by mailfhigh.phl.internal (Postfix) with ESMTP id 07D681140139 for <9front@9front.org>; Mon, 28 Oct 2024 20:36:57 -0400 (EDT) Received: from phl-imap-05 ([10.202.2.95]) by phl-compute-07.internal (MEProxy); Mon, 28 Oct 2024 20:36:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cranky.ca; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1730162217; x=1730248617; bh=+N7x1akaaX7njizXL/W2ZxRbU4o4HYxsmV+LmOby+3I=; b= aXn4uWvGkU5pbBzPX5+heR8+5u3fF5f9XcULT8iyyJ7nSDUd+k93m6ntx2D1q8Hr eXYs42wRyVsI818G79o2ZA19V8MKcnfI8btVvQmvIKNkTalXDlPq2eAOrWkpJiap 49wiL16TJHJW/UelK0xs9iz0zcxgCWzkdZVPos/TTivqOVI4JS7XfaoV1IYtpixY Sgt/6U88CTgXdVBvLAzO+h+K4JGCJMJu1qXK5b0kU3BmA5RKxJCCbdNWYaE5qK/+ AfH5h/I2JzpC2aVVboR1/3A75uQN9N59K9sC9RcY8sqJU415wMC164AdwxWtwrIU P0H0gDUT5rjwrNPMjdB1cg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1730162217; x=1730248617; bh=+ N7x1akaaX7njizXL/W2ZxRbU4o4HYxsmV+LmOby+3I=; b=XV1zaSO20ZysQkK6C epJtrkeYvpz/poJK3VMuFiCgkVSS95yB3xb9YZT48aZnXscKsG+3G8ALL4qIAkWL 9ifE/YPvMxUFJXStLivK29IN3FIIRWVNX3L+P9I/OvzRwmQcO21ks+fCCQZZuEt+ XGqWVToTk4wwlc3e9bt1S0sLv538T4ZUeGEA5K7G1vUrG6WHuLv/goieemzj0hW+ 91ACnHNyCiht3jGlf+ovVDfO+urMXjtWQfRKYHEutMddn9BF0r367dIHR01+oFNA OO68m1G2jSNQzoNR2kZYEAwmFXTJF07GIP+Z5TjnIGoCSyJr3S0JpLCLetWbc9pI Dg9Kg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvdektddgvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefoggffhf fvkfgjfhfutgfgsehtqhertdertdejnecuhfhrohhmpedfufgtohhtthcuhfhlohifvghr shdfuceofhhlohifvghrshhssegtrhgrnhhkhidrtggrqeenucggtffrrghtthgvrhhnpe etfeegtdeiudeukeevleetkeekvdejvdeiteeuieeuvdehfefghedvvdegkedvvdenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehflhhofigvrh hsshestghrrghnkhihrdgtrgdpnhgspghrtghpthhtohepuddpmhhouggvpehsmhhtphho uhhtpdhrtghpthhtoheplehfrhhonhhtseelfhhrohhnthdrohhrgh X-ME-Proxy: Feedback-ID: i1e6c46d8:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id A20C03020083; Mon, 28 Oct 2024 20:36:56 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface MIME-Version: 1.0 Date: Mon, 28 Oct 2024 18:35:30 -0600 From: "Scott Flowers" To: 9front@9front.org Message-Id: In-Reply-To: References: <588564A0F1AB6824ED04551648A54C37@cranky.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: overflow-preventing social out-scaling-scale generator Subject: Re: [9front] Bug or inconsistency in cursor behaviour? Reply-To: 9front@9front.org Precedence: bulk Well, my original email was intended to say more like "Is this a bug?" r= ather than "This is a bug!" Then, in the event that anyone thought it wa= s a bug, in anticipation of somebody going "Patches welcome!" I made a p= atch. I understand your explanation of the selected text BEING the cursor and = so the rio and acme behaviour make sense in that context. I'm still not = clear on whether sam acts differently because of history, a limitation o= f its original hardware, or some kind of deeply thought out reason I don= 't know about. Sam to me is mysterious and inscrutable. I'll go see if I can find that thread on 9fans, which admittedly I don't= frequent. Scott On Mon, 28 Oct 2024, at 17:45, Thaddeus Woskowiak wrote: > What makes you call the cursor behavior of Plan 9 odd or a bug? Just > because it doesn't behave like one of the big three does not mean it > is broken. Sam predates Plan 9 originating on Unix and ran on the Blit > terminals so it has different roots. >=20 > And if memory serves me correctly there is a rant on 9fans explaining > this exact expectation of cursor behavior (Boyd Roberts or BruceE > maybe?). Basically the current expected behavior originated from > Windows and copied by others. >=20 > There is a logical argument to the Plan 9 behavior: First, the cursor > disappears when you make a selection because the cursor *IS* the > selection. So if the selection is the cursor then it makes sense that > pressing an arrow key moves the cursor one character over in that > direction. The Windows way is odd because the cursor does not move > when you first press the arrow key which breaks cursor logic. I > believe this is the same argument presented in the 9fans post I > mentioned though more nuanced. >=20 > On Mon, Oct 28, 2024 at 4:21=E2=80=AFPM wrote: > > > > I have noticed an odd behaviour when using the arrow keys when text = is selected in 9front, and I'm wondering if it's a bug, multiple bugs, o= r just the way things work. > > > > If I have a string of text in a shell or acme, and I select one or m= ore characters with the mouse, and then use the right arrow key, the tex= t gets deselected, and the cursor moves one character past the right end= of the selected text. If I use the left arrow key, the cursor moves to = one character to the left of the previously selected text. It feels like= the resultin position of the cursor has gone one character too far left= or right. > > > > In sam, this behaviour is different. If I select text in sam, and th= en hit the left arrow key, the cursor moves one character to the left of= the initially selected text, and if I hit the right arrow key, the curs= or moves to the right of the first character of the previously selected = text. This also seems odd. > > > > In Windows, MacOS and all the Linux graphical text manipulation apps= I have tried, if you select text and then hit the left arrow, the curso= r moves to the beginning of the selection, and the right arrow moves to = the end of the selection. This feels like the more appropriate behaviour= to me. Am I out to lunch? > > > > Thanks, > > > > Scott >=20