fix unexpected first selection when splitting #7854
Conversation
brendonh8
changed the title
| // In contrast to the comment above, there is no | ||
| // _trailing_ zero-width range despite the trailing | ||
| // match, because ranges are exclusive on the right. | ||
| Range::new(20, 20), |
There was a problem hiding this comment.
I believe we don't want this trailing point either. With (essentially) the same reproduction case as #3850: i| | | |<esc>%_S\|<ret>: we have a trailing selection created at the end which lives outside of the selection at the start of S (when the selection is over | | | |). I believe that case should leave only the spaces between the |s selected.
| result.push(Range::new(start, end)); | ||
| let range = Range::new(start, end); | ||
| // Don't add a zero-width range if a match is at the start of selection | ||
| if range != Range::point(sel.from()) { |
There was a problem hiding this comment.
I wonder if it is enough to test that the range is not a point? Is there any case where we want a selection over a zero-width match?
There was a problem hiding this comment.
yeah I actually think helix currently handles zero width matches weirdly. For example you can currently use an emply anchor match ^$ to match empty lines (or | to match every char index) in helix. This works for forward search but not reverse search. This behavior is incorrect. I think we should always ignore zero-width matches so that there is always some unambiguous text to select.
There may be an argument that you want to keep search working in that case (since you could view that as selection being a secondary instead of primary effect) but for s in particular the primary goal is to select the text which matches the regex pattern and ^$ matches no text (and for consistency and avoiding weird edgecases I think we should do the same for search)
the-mikedavis
added
C-bug
fixes #3850
Original logic was intentionally following inclusivity similar to
Rangefor returned selections after splitting, so inclusive on left and exclusive on right. However, when you have a match right at the start of a selection, you will get a returned selection before that initial match. This doesn't make sense when the rest of the selections will always come after a match.