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

["Scott Flowers" <flowerss@cranky.ca>]

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
>