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 4E78D309C7 for ; Tue, 29 Oct 2024 00:01:08 +0100 (CET) Received: from fout-b6-smtp.messagingengine.com ([202.12.124.149]) by 9front; Mon Oct 28 19:00:13 -0400 2024 Received: from phl-compute-07.internal (phl-compute-07.phl.internal [10.202.2.47]) by mailfout.stl.internal (Postfix) with ESMTP id 27201114013E for <9front@9front.org>; Mon, 28 Oct 2024 19:00:12 -0400 (EDT) Received: from phl-imap-05 ([10.202.2.95]) by phl-compute-07.internal (MEProxy); Mon, 28 Oct 2024 19:00:12 -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=1730156411; x=1730242811; bh=PFOlVIardJQH/FgxVdE9g7eiRzeFQW6LnjO1C+p9Euo=; b= dcRJVhI9cM6775icAp96C6o4n25Yl2xrvlSWtkyBkBCnok6T8lYDDOCYtImJXZsb F09zQ2AwWncRxJCSNWsbl+7QjeqCuzaahUwTcUb6kkCAwPs5B0c7cJMCs0zr1UNx BpzbM3odm4VqPF6sspKayxuCSb8bLN3SjpVbf1QV36qMp/E1bPLRf6T/Kv/ruyFy wSeGWGjXeRrHrzPjcY8Ai0OHCKo2kfXpp6WI89f/e6worvuBTuuzyhzeUewK77Xe zAmfAb6Hb77u5ah0uAkLqtJvU5mmHsAv1heVJdKdDhEzly3eAD9AbfPh4g+xx52D b4aZCIIO36ZlCAO0084imQ== 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-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1730156411; x= 1730242811; bh=PFOlVIardJQH/FgxVdE9g7eiRzeFQW6LnjO1C+p9Euo=; b=b Vf8pLza6M0BeGgtQUoNa35NWXWrPqqpnXJuubyNHZ+Cds+ZJ8HNrjK7UlWhBG2ic 6CvH20gJuuVMXe9Q8sYTWTQOhxnFsQnxf88BSfbkc09hdCZklb5m3PVaDZgcF4Dx im7VUGgJIMlEg+j5PCgd2uD5sNpwAp+GToddnZEnhuE+2zef7HjkOnkI7sWcsBaq 7cQ5bx9inYQZai/HoIBBNMxtzmCDfvPm/zf1d1uYIZR19QRLkfZOqTtgzsxD0UuR 4BENKfwCM4IhcnTPci9xyuFJSW79fXD9h4HsQFVy4tcJ08UU5whWsJL7y/D1/K7M gw9qjeic0EKHuw+m7l13A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvdektddgtdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefoggffhf fvkfgjfhfutgfgsehtjeertdertddtnecuhfhrohhmpedfufgtohhtthcuhfhlohifvghr shdfuceofhhlohifvghrshhssegtrhgrnhhkhidrtggrqeenucggtffrrghtthgvrhhnpe duhfegtedvjeetteeffefhieetveejveeigfejveelffffgeeuveetvddvjeeuueenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehflhhofigvrh hsshestghrrghnkhihrdgtrgdpnhgspghrtghpthhtohepuddpmhhouggvpehsmhhtphho uhhtpdhrtghpthhtoheplehfrhhonhhtseelfhhrohhnthdrohhrgh X-ME-Proxy: Feedback-ID: i1e6c46d8:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 9DA763020080; Mon, 28 Oct 2024 19:00:11 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface MIME-Version: 1.0 Date: Mon, 28 Oct 2024 16:59:50 -0600 From: "Scott Flowers" To: 9front@9front.org Message-Id: In-Reply-To: References: <588564A0F1AB6824ED04551648A54C37@cranky.ca> Content-Type: text/plain Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: patented out-scaling core-scale solution Subject: Re: [9front] Bug or inconsistency in cursor behaviour? Reply-To: 9front@9front.org Precedence: bulk Please ignore the first set of patches, I arsed up the one for rio. Scott Flowers flowerss@cranky.ca On Mon, 28 Oct 2024, at 16:49, Scott Flowers wrote: > If interested, patch for acme, patch for rio below. Apologies for my non-c-programmerness. > > diff 6894c4e13a24e9983e2daf4ee2566f8396d29f4e uncommitted > --- a/sys/src/cmd/acme/text.c > +++ b/sys/src/cmd/acme/text.c > @@ -680,13 +680,24 @@ > switch(r){ > case Kleft: > typecommit(t); > - if(t->q0 > 0) > - textshow(t, t->q0-1, t->q0-1, TRUE); > + if(t->q0 > 0) { > + if(t->q0 != t->q1) { > + textshow(t, t->q0, t->q0, TRUE); > + } > + else { > + textshow(t, t->q0-1, t->q0-1, TRUE); > + } > + } > return; > case Kright: > typecommit(t); > if(t->q1 < t->file->nc) > - textshow(t, t->q1+1, t->q1+1, TRUE); > + if(t->q0 != t->q1) { > + textshow(t, t->q1, t->q1, TRUE); > + } > + else { > + textshow(t, t->q1+1, t->q1+1, TRUE); > + } > return; > case Kdown: > n = t->maxlines/3; > > diff 6894c4e13a24e9983e2daf4ee2566f8396d29f4e uncommitted > --- a/sys/src/cmd/rio/wind.c > +++ b/sys/src/cmd/rio/wind.c > @@ -892,16 +892,30 @@ > return; > case Kleft: > if(w->q0 > 0){ > - q0 = w->q0-1; > - wsetselect(w, q0, q0); > - wshow(w, q0); > + if(w->q1 != w->q0) { > + q0 = w->q0; > + wsetselect(w, q0, q0); > + wshow(w, q0); > + } > + else { > + q0 = w->q0-1; > + wsetselect(w, q0, q0); > + wshow(w, q0); > + } > } > return; > case Kright: > if(w->q1 < w->nr){ > - q1 = w->q1+1; > - wsetselect(w, q1, q1); > - wshow(w, q1); > + if(w->q1 != w->q0) { > + q1 = w->q1; > + wsetselect(w, q1, q1); > + wshow(w, q1); > + } > + else { > + q1 = w->q1+1; > + wsetselect(w, q1, q1); > + wshow(w, q1); > + } > } > return; > case Khome: > > > > Scott > > On Mon, 28 Oct 2024, at 14:19, flowerss@cranky.ca 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, or just the way things work. > > > > If I have a string of text in a shell or acme, and I select one or more characters with the mouse, and then use the right arrow key, the text 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 then 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 cursor 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 cursor 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 > > >