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