bugGNU nano - Bugs: bug #53195, a shift selection should be...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #53195: a shift selection should be cancelled on any unshifted arrow keypress

Submitter:  Brand Huntsman <brand>
Submitted:  Wed 21 Feb 2018 02:16:31 AM UTC
   
 
Severity:  3 - Normal Status:  Fixed
Assigned to:  bens Open/Closed:  Closed

Jump to the original submission

Fri 09 Mar 2018 10:17:12 AM UTC, comment #8: 

Released in 2.9.4.

Benno Schulenberg <bens>
Group administrator
Tue 27 Feb 2018 05:13:30 PM UTC, comment #7: 

Fixed in git, commit 6f4f1878.

Benno Schulenberg <bens>
Group administrator
Sun 25 Feb 2018 07:25:53 PM UTC, comment #6: 

Good catch; I misspoke.  The hard mark would still be needed if you wanted to preserve the mark when using non-arrow movement functions, so yes, I meant the first one.

And thank you with regard to the comment.

David Lawrence Ramsey <dolorous>
Group Member
Sun 25 Feb 2018 07:04:36 PM UTC, comment #5: 

When you say that "movement functions other than the arrows are important too", I guess you mean that such movement functions (like M-G and ^W) should cancel the softmark too?  If yes, then it would be the first patch (the "any" patch) that you prefer.

Locally I've added a comment about the assumption in the commit message.  (Not pushed yet.)

Benno Schulenberg <bens>
Group administrator
Sun 25 Feb 2018 06:31:36 PM UTC, comment #4: 

Okay.  Not canceling the softmark unnecessarily is good; this just counts as a minor tweak regarding movement.

The second patch seems better to me, since movement functions other than the arrows are important too.  I don't mind the assumption that all movement functions are in move.c either.  (Although maybe the patch should also add a quick comment mentioning that assumption?)

David Lawrence Ramsey <dolorous>
Group Member
Sun 25 Feb 2018 09:30:57 AM UTC, comment #3: 

Okay.  I agree that an attempt to move the cursor should count as if the cursor actually did move.

As to a use case where a non-volatile Shift selection comes in handy... I do not have one.  I just want ^G^G and ^C and M-X and any other toggle to not cancel the softmark -- I want to keep bug #52470 fixed.

Attached patches achieve that.  The second one even keeps a Shift selection when ^W or M-G is used.  They are slightly ugly because they count on all movement functions to be in src/move.c, but... that ought to be the case.

Which of these two patches do you prefer?

(file #43396, file #43397)

Benno Schulenberg <bens>
Group administrator
Sat 24 Feb 2018 05:30:59 PM UTC, comment #2: 

Despite it's not being on the mailing list, chiming in for the record...

I'm with Brand.  I would say it is more logical, in that an unshifted arrow key is an attempt to move the cursor, and should count whether the move succeeds or not.

More importantly, I'm not for nano's blindly following the behavior of every other editor, but if nano doesn't follow the behavior of every other editor, I figure there should be a good reason for that, and I don't see one here.

Although, to be fair... Benno: Are there some specific use cases where a not-so-volatile Shift-selected region comes in handy?  If/When this gets on the mailing list, you could answer that question there instead of here, but it would be useful to know.

David Lawrence Ramsey <dolorous>
Group Member
Wed 21 Feb 2018 11:17:25 AM UTC, comment #1: 

I wouldn't say that it is more logical, but it is what other programs do that allow making a selection by holding Shift.  I kind of like it that the Shift-selected region isn't so volatile.  It's easy enough to make the selection disappear: move the cursor.

If you think that nano should follow the behavior of other programs, please propose this on the mailing list.  I don't see the current behavior per se as a bug.

Benno Schulenberg <bens>
Group administrator
Wed 21 Feb 2018 02:16:31 AM UTC, original submission:  

Shift-select to end of buffer and then press down or right arrow keys. Or shift-select to start of buffer and then press up or left arrows keys. The cursor is unable to move and the selection remains. It would be more logical if the shift-selection was removed even if the cursor can't move.

Brand Huntsman <brand>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by dolorous (Posted a comment)
  • -email is unavailable- added by bens (Posted a comment)
  • -email is unavailable- added by brand (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-03-09 bens Open/ClosedOpen Closed
    2018-02-27 bens StatusIn Progress Fixed
    2018-02-25 bens Attached File- Added 0001-selecting-cancel-the-softmark-upon-any-attempt-to-mo.patch, #43396
        Attached File- Added 0001-selecting-cancel-the-softmark-upon-an-attempt-to-mov.patch, #43397
        StatusNone In Progress
        Assigned toNone bens
    2018-02-21 bens Summaryunhighlight shift selection on any unshifted arrow keypress a shift selection should be cancelled on any unshifted arrow keypress

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code