[9front] Bug or inconsistency in cursor behaviour?

[9front] Bug or inconsistency in cursor behaviour?

[flowerss]

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

Re: [9front] Bug or inconsistency in cursor behaviour?

[Scott Flowers]

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
> 

Re: [9front] Bug or inconsistency in cursor behaviour?

[Scott Flowers]

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
> > 
> 

Re: [9front] Bug or inconsistency in cursor behaviour?

[Scott Flowers]

Actually, ignore that recommendation to ignore that patch. I panicked. I chalk it up to first-patch-submission jitters. Below will make acme and rio left and right arrow keys move the cursor to the beginning and end of selected text respectively, instead of one extra character left or right.

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:

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;

Thanks,

Scott

Re: [9front] Bug or inconsistency in cursor behaviour?

[Thaddeus Woskowiak]

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 PM <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

Re: [9front] Bug or inconsistency in cursor behaviour?

[Scott Flowers]

Well, my original email was intended to say more like "Is this a bug?" rather than "This is a bug!" Then, in the event that anyone thought it was a bug, in anticipation of somebody going "Patches welcome!" I made a patch.

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 of 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.
> 
> 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 PM <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
> 

Re: [9front] Bug or inconsistency in cursor behaviour?

[hiro]

> 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.

Re: [9front] Bug or inconsistency in cursor behaviour?

[Scott Flowers]

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.
> 

Re: [9front] Bug or inconsistency in cursor behaviour?

[hiro]

your fingers are correct to reject this cybernetic failure. proper
thought into how to improve this sad resulting human intellect has
ceased 40 years ago.

On Tue, Oct 29, 2024 at 4:18 PM Scott Flowers <flowerss@cranky.ca> wrote:
>
> 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.
> >

Re: [9front] Bug or inconsistency in cursor behaviour?

[hiro]

sorry. 60 years. (i'm not that old, so my memory is a bit fuzzy).

On Tue, Oct 29, 2024 at 6:40 PM hiro <23hiro@gmail.com> wrote:
>
> your fingers are correct to reject this cybernetic failure. proper
> thought into how to improve this sad resulting human intellect has
> ceased 40 years ago.
>
> On Tue, Oct 29, 2024 at 4:18 PM Scott Flowers <flowerss@cranky.ca> wrote:
> >
> > 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.
> > >

Re: [9front] Bug or inconsistency in cursor behaviour?

[ori]

Quoth flowerss@cranky.ca:
> 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.

This is intentional, just a different way that things work. An arrow just moves
the dot.

> 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.
>

This one, I'd call a bug.
 
> 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

Re: [9front] Bug or inconsistency in cursor behaviour?

[Scott Flowers]

Figures. The ones that i can figure out how to change are not bugs and the one that I can't figure out how to change might be one.

Scott 

On Mon, 28 Oct 2024, at 19:40, ori@eigenstate.org wrote:
> Quoth flowerss@cranky.ca:
> > 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.
> 
> This is intentional, just a different way that things work. An arrow just moves
> the dot.
> 
> > 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.
> >
> 
> This one, I'd call a bug.
>  
> > 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
> 
> 

Re: [9front] Bug or inconsistency in cursor behaviour?

[umbraticus]

It's not a bug; it's a choice. See also backspace behaviour.
Probably programs should agree to make the same choice.

Next you can decide what finger contortion should be used for
extending and contracting dot, moving by larger distances, &c.

umbraticus

Re: [9front] Bug or inconsistency in cursor behaviour?

[hiro]

our bugs span many more dimensions than just spiritual weakness.