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_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 34FC52F75C for ; Tue, 29 Oct 2024 00:48:53 +0100 (CET) Received: from mail-ed1-f51.google.com ([209.85.208.51]) by 9front; Mon Oct 28 19:46:01 -0400 2024 Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-5c94861ee25so2760699a12.0 for <9front@9front.org>; Mon, 28 Oct 2024 16:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730159157; x=1730763957; darn=9front.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=9M9i5quR7Mipv8D7EwjT7lI4gz0RY3YhRwHEayErhKA=; b=esi62WTIfY8aFPM82DimoAFrFMrZMXYZGhQMPyuFZpkmBHXZoDj4V5NTwEza/ZTNVb szGvbuqahjPiiEsKpCoZbYWhgTDbXuuh6xdJ2DiKDlijZ8OwyD/mCRdmiECU5jz8ZCz1 RidClO2HxSXQWNrNE/F56wc970Aw2jK8iN3mL/Xxw0WoKjZNhSc9JEXOhnUTRjXaDSyN kB3p1d0eXzCyhcTnOggRUG0j8yOWKeEHVK4a1edsXicovACNaYnP5IgGmKpawnlcXyO7 gte+iYniRL8w74Yx/cTxm9july3gYNtvx7tsTqDnrqiSqD+/lnD9QUN6e+lLJkWZwBeV w66g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730159157; x=1730763957; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=9M9i5quR7Mipv8D7EwjT7lI4gz0RY3YhRwHEayErhKA=; b=Jf93+O2Mo7NKJ2iD1oATNAYD/p91aOJeGkUFmhwTwg0XkWN/xXZXoHe5yJGI5VUHrs FIwCNXld8fSZgjqxMY69zBjZ118DGnKmEwdd5cQcvY5zp0FZzPyKSs7VUae2XCQ38YzY G5zAO2pvkXp5A1hO4wSFb7SoLcn17SvNpGG/w3K3b6HlUsp0g+Gwhru9UfpQPMSxc8hR eHffGZhXvlMnPqm5zQAItBbYgb386/05k6WZIz9va6rTBaDE4eRsBOnCCP+8fQQG5ERX RxFmFmIDRE7za/D02KkUzF+t72qrH3Cjk7HVETjjSIc50ao3BMbCBoY2cLphkI46pyc6 mgcg== X-Gm-Message-State: AOJu0Ywt9gdYzGqRMPdL7JEKQ7A8GTvSCciEbyaz37KeNRWzUfgXqmWM nNvQ5KS0qarKqep/GgQlOsLSTYrzX3rxLy3kIq/cprd9wCB2uVXX3EpucAWvJmTjaarQP4R0utn dIOupIr5paLlKNuDRZc5JhIVfDBJIBhn6 X-Google-Smtp-Source: AGHT+IFHuLGP3hKUiDH34z2pv0yZiau8fHITdwmtUWVg7SVCW6PYyVksg6rcL+tZokBUa1LFSlEpvK16wP1NZi6wRlc= X-Received: by 2002:a05:6402:5188:b0:5cb:f1d7:56ac with SMTP id 4fb4d7f45d1cf-5cbf1d75726mr1496776a12.2.1730159157311; Mon, 28 Oct 2024 16:45:57 -0700 (PDT) MIME-Version: 1.0 References: <588564A0F1AB6824ED04551648A54C37@cranky.ca> In-Reply-To: <588564A0F1AB6824ED04551648A54C37@cranky.ca> From: Thaddeus Woskowiak Date: Mon, 28 Oct 2024 19:45:21 -0400 Message-ID: To: 9front@9front.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: distributed template-aware framework SQL over JSON software proxy app STM solution Subject: Re: [9front] Bug or inconsistency in cursor behaviour? Reply-To: 9front@9front.org Precedence: bulk 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. 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. 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. 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 se= lected in 9front, and I'm wondering if it's a bug, multiple bugs, or just t= he way things work. > > If I have a string of text in a shell or acme, and I select one or more c= haracters with the mouse, and then use the right arrow key, the text gets d= eselected, and the cursor moves one character past the right end of the sel= ected 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 pos= ition 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 hi= t the left arrow key, the cursor moves one character to the left of the ini= tially 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 als= o seems odd. > > In Windows, MacOS and all the Linux graphical text manipulation apps I ha= ve 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 o= ut to lunch? > > Thanks, > > Scott