Having tried this out in Edit, I don't think this behaves consistently with the cut'n'paste spec.
The problem occurs when there are several consecutive lines comprising only newlines. You can drag the mouse over them (which now shows a caret on the first line), and then you can cut the selection to the clipboard - and the cut'n'paste spec says when we show a caret there is no selection.
In ASCII art an example is
The quick brown fox
I <-- drag select from here...
<-- ...to here
jumps over the lazy dog
Other editors I have to hand deal with this by showing the selection of an empty line as a solid block. In StrongEd that's a block to the end of the line, in Notepad++ (Windows) it invents a single space and colours that blue.
Aside: I looked at this bug about 2 years ago, and there's a more localised way to deal with the specific found selection case, by looking for case txtedit_FiGo
in txtedit.c, there are 5 pairs of txt_setdot/txtscrap_setselect which can be replaced by <some logic> to handle a \n magic string. This also avoids having to scan the text on each change of owner of selection which strikes me as inefficient. However, it still results in a nonsense of a selection (which can be replaced) being rendered as a caret (which by definition is no selection).