[TxMt] A fix for Move Selection Line Up/Down and suggestions for TextMate

Sergei Yakovlev sergei.yakovlev at gmail.com
Sun Dec 30 19:13:34 UTC 2007

On Dec 26, 2007, at 10:28 PM, Allan Odgaard wrote:

On 26 Dec 2007, at 14:28, Сергей Яковлев wrote:

  Suggestion 1. It would be useful if TextMate had
  variables like $TM_SELECTION_START and
  $TM_SELECTION_END which would return the
  corresponding offsets in the file (or the cursor
  offset, if nothing is selected).

It does in the form of a line/column position of the start position.

Maybe I am simply misunderstanding you, but are you saying that
TextMate returns line and column position of the start position of

I'm asking because the $TM_LINE_NUMBER and
$TM_COLUMN_NUMBER variables don't quite work this way.

To illustrate what I mean, let's add a 'Show Position' command
that displays position as a tooltip:


and type 'TextMate' into an empty document. Now, if we select
'TextMate' with mouse from left to right, the command returns 1:9.
If we select 'TextMate' with mouse from right to left, the command
returns 1:1. Finally, if we select 'TextMate' by double-clicking
between 't' and 'M', the command returns 1:5.

So, these variables actually return the cursor position, not the
starting position of selection and it is impossible to calculate the
starting and ending positions of selection from
(without knowing how the selection was made).

The only way to do this (that is known to me) is to write a macro that
first calls a command that replaces selection with itself wrapped in
U+FFFC characters:

    echo -n $'\357\277\274'$TM_SELECTED_TEXT$'\357\277\274'

and then calls another command that receives the whole document
as an input and can "find" the selection looking for U+FFFC

It would certainly be easier for the average user (and somewhat
more flexible) if TextMate had something like
variables, or, alternatively, slightly changed semantics of
so that they always return the starting position of selection
(no matter how the selection was made).

The reason it does not use a byte offset is that internally TM would have to
"calculate" this (by adding the length of each line preceding the selection)
and I am generally wary of exporting shell variables that need to be
calculated and have an unknown running time (i.e. in practice the user could
have a million lines and each command execution would then always require a
million numbers to be added together).

I assumed that these calculations were already being performed,
after I had a look at:

    $ class-dump -C OakTextView TextMate | grep selectedRange
    - (struct _NSRange)selectedRange;
    - (void)setMarkedText:(id)fp8 selectedRange:(struct _NSRange)fp12;

and saw 'selectedRange'. But, evidently, something much more
complicated is going on, and I certainly would not ask you questions
about TextMate internal workings :-)

The only remaining question is what symbol to use as a
mark. I decided to use √ (221A, SQUARE ROOT character,
which you can type with Option-V), but I'm not sure
this is the best choice. Maybe it's better to use some
character from Private Use Area (E000--F8FF)?


I've attached a new version of macros using U+FFFC to the original ticket.

Happy New Year!

-- Sergei Yakovlev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macromates.com/textmate/attachments/20071230/34b0daba/attachment.html>

More information about the textmate mailing list