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 A7CB330AC2 for ; Tue, 29 Oct 2024 16:19:16 +0100 (CET) Received: from fout-a3-smtp.messagingengine.com ([103.168.172.146]) by 9front; Tue Oct 29 11:17:30 -0400 2024 Received: from phl-compute-07.internal (phl-compute-07.phl.internal [10.202.2.47]) by mailfout.phl.internal (Postfix) with ESMTP id 93A78138011A for <9front@9front.org>; Tue, 29 Oct 2024 11:17:28 -0400 (EDT) Received: from phl-imap-05 ([10.202.2.95]) by phl-compute-07.internal (MEProxy); Tue, 29 Oct 2024 11:17:28 -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=1730215048; x=1730301448; bh=d6ipHmi89oKC7gv23cdekrn8B7AXCYDO3RKR/oHf0UY=; b= b5EurhVtfM0dF3BmJ0p7u99PsnZVpalPMxJB2Du4txLUP0wHMCxuSXoKNRuRMDKj 8R+VCjZwv3h3+33CK3XwutSjyvvXDcjGcsWdnosjJEVLTJlsmKcHMlTRZDE3p6mf 4RDoZrtM3jg+BO+x3jGccU+P3G5m+W8BiHeMg/gJm78ATHS6ABGcJW2wldiftUNE 5CF3FKJSh2PAVCxN7pXIwfyIsIPFIeFO02mK1ytB13u+hWGS/oDnNyEqnhIxWEN6 F8IW9IyfWQoICPdWjdI26/CyPa1wKSFRKHhTA9eR/F5a0oBwxXlLDj+8Gf8vrgbg wut7Btvrg/F0ngNgH1EJ6Q== 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=1730215048; x=1730301448; bh=d 6ipHmi89oKC7gv23cdekrn8B7AXCYDO3RKR/oHf0UY=; b=BSSFMd0hfc2d8hJyO U/LVUSu1CRaEYGP9cckUO6CA6U8mltIil6bYfSEXqtymhgUJHTtBpho7mL9JOe6b 2+zhqOIvbvbfrE8cR5kcObaCJSNrNwKM+RyZpxYqW+wEUCc7E+LFHj4qeP3jKoa+ XmgWMdWCRWcgKxjS01/FFG90jHX/PqtNDqNeJXnAiQmLobwOq2dMT0f8gvyN3iDU dj0Cj/HDhUYyXuM0xA97UIum5VArA/l4yd64GD3D94KzxUtf9Ok2dTg8IRt3Ys8Y TwmbL3yRXgPLfRP96u60omUGcYKiwJ9nZDTgmZG2lrI811s8yU9OSaVUSgxGHEl+ jl46Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvdekuddgjedtucetufdoteggodetrfdotf 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 3B16C3020083; Tue, 29 Oct 2024 11:17:28 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface MIME-Version: 1.0 Date: Tue, 29 Oct 2024 09:16:48 -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: property pipelining out-scaling standard module STM controller Subject: Re: [9front] Bug or inconsistency in cursor behaviour? Reply-To: 9front@9front.org Precedence: bulk I am declaring my fingers' inability to get used to the existing behaviour in rio and acme to be a human software bug, and I'm keeping my patch on my machines. As Sigrid once said, "it's your system, do what you want." Scott On Tue, 29 Oct 2024, at 03:59, hiro wrote: > > 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. > > may i point out that this is the perceived behavior on windows due to > common vision limitations? the designers were aware of this visual > difficulty or they wouldn't have made the cursor blink. yet the edge > becomes nearly-undetectable in the edge-case of selection. who knows > if they ever noticed the lack of intuition in this pattern? > > regardless there remains a logic i feel some plan9 folks might not > know about: the blinking cursor helps suggest whether selection will > be added to or removed from via keyboard actions > (shift-left/shift-right), a feature that does not exist on plan9. > otherwise it exclusively confuses the well-sighted. at least in some > applications: i'm not sure if rob pike managed to infiltrate the > mozilla headquarters and forced them to remove that cursor, but it's > missing in my firefox. >