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

[Sergei Yakovlev]

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
selection?

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:

    echo "$TM_LINE_NUMBER:$TM_COLUMN_NUMBER"

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
$TM_LINE_NUMBER and $TM_COLUMN_NUMBER variables
(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
characters.

It would certainly be easier for the average user (and somewhat
more flexible) if TextMate had something like
$TM_SELECTED_TEXT_START_LINE_NUMBER and
$TM_SELECTED_TEXT_START_COLUMN_NUMBER
variables, or, alternatively, slightly changed semantics of
$TM_LINE_NUMBER and $TM_COLUMN_NUMBER variables
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)?


We generally use U+FFFC, OBJECT REPLACEMENT CHARACTER.


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>