#1633 Delete word right should invalidate selection

Bug
closed-fixed
Neil Hodgson
5
2014-08-14
2014-08-04
Ian Goldby
No

Steps to reproduce:

  1. Make a multi-line selection in the direction bottom to top so the caret is at the start of the selection.
  2. Press Ctrl+Del (delete word right = SCI_DELWORDRIGHT).
    Expected result: The selection is cleared and the word to the right of the caret is deleted.
    Actual result: The selection is not cleared on the other lines, but it does become cleared when those lines are next redrawn.

The same thing happens with SCI_DELWORDLEFT, SCI_DELLINELEFT, SCI_DELLINERIGHT, SCI_LINEDELETE.

The problem doesn't occur if the text is styled.

SciTE 3.4.4 on Windows.

Discussion

  • Neil Hodgson
    Neil Hodgson
    2014-08-04

    • labels: --> scintilla, selection
    • status: open --> open-accepted
    • assigned_to: Neil Hodgson
     
  • Neil Hodgson
    Neil Hodgson
    2014-08-05

    SCI_DELWORDRIGHT is reproducible. It appears that this can be fixed by adding to the start of this case
    InvalidateSelection(sel.RangeMain(), true);

    SCI_DELWORDLEFT, SCI_DELLINELEFT, SCI_DELLINERIGHT, and SCI_LINEDELETE leave the remainder selected even after a redraw. This is with SciTE set to Text. Perhaps there are other settings involved.

    The precise behaviour of some of these APIs with various selection modes may be changed if there are better alternatives.

     
  • Ian Goldby
    Ian Goldby
    2014-08-05

    You are quite correct. I assumed that for consistency SCI_DELWORDLEFT, SCI_DELLINELEFT, SCI_DELLINERIGHT, and SCI_LINEDELETE would drop the selection before performing the delete, and I never checked that the selection drawing would disappear when I forced a redraw.

    Personally, I think these 5 commands should all drop the selection, and then make a deletion based on the main caret position. If they don't drop the selection then it would be fair to expect them to operate on the selection itself, which isn't exactly useful or what the user would want.

     
  • Neil Hodgson
    Neil Hodgson
    2014-08-05

    Committed fix as [4935d4].

    I have some sympathy for the drop selection viewpoint. The opposing view is that the user has chosen to make that selection by holding the shift key, so it should be maintained unless the user chooses. There are also various forms of consistency that can be argued.

     

    Related

    Commit: [4935d4]

  • Neil Hodgson
    Neil Hodgson
    2014-08-05

    • status: open-accepted --> open-fixed
     
  • Neil Hodgson
    Neil Hodgson
    2014-08-14

    • status: open-fixed --> closed-fixed