<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"> On 16.01.2014, at 04:29, Allan Odgaard <<a href="mailto:mailinglist@textmate.org">mailinglist@textmate.org</a>> wrote: <blockquote type="cite">On 15 Jan 2014, at 20:57, Kai Wood wrote: <blockquote type="cite" style="font-family: DejaVuSansMono; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">TM_SELECTION is now "6-3”, the range now includes line 6, but the *visible* part of the selection is still 3-5 […] Can this be considered a bug or is it intended behavior / a feature? </blockquote> I believe it is correct behavior. Line 6-3 is short for 6:1-3:1. This means the selection goes from line 3, column 1, to line 6, column 1. As you say yourself, you can check if the newline is included, to test if the last line in the selection is an “empty line”. Had the newline not been included in the selection, TM_SELECTION would be 5:5-3. I.e. starting at line 3, column 1, and ending on line 5, column 5 (including all characters on line 5 except the trailing newline). </blockquote> <div>Ok, i finally found the edge case that was driving me nuts :) Take this column selection, made via Shift+UP and tapping option: <img apple-inline="yes" id="3598E42E-F044-4260-8CB4-290A1514E564" height="126" width="264" apple-width="yes" apple-height="yes" src="cid:B7DB1C1A-8D44-4CDF-AE32-D3963D868EE9@boerding.local"> TM_SELECTED_TEXT now holds “\n\n”, TM_SELECTION is "4:3x2:3”. As soon as I’m moving to the right and back left via the cursors, TM_SELECTED_TEXT changes to nil and the selection string is now "2:3&3:3&4:3”. Even if i press CMD-L to mark the whole lines, TM_SELECTED_TEXT still contains “nil”. It’s clear that internally the cursors change from some kind of “normal” column selection to multi-cursors, as one can see considering the selection string (initial separator “x”, post movement separator “&"). In my use case, I can still distinguish this state of the cursors by parsing the selection string, but it’s a little more complicated than relying on the newline. Just wanted to share this if someone trips over something similar, i guess it’s nothing that should (or can) be fixed - just a side effect of the multicursor implementation.</div><div> </div></body></html>