#516 -goto: column counts tabs wrongly

[Avi Halachmi]

When using "-goto:<line>,<col>", it counts the characters from the beginning of the line rather than moving to the target column.

This affects the behavior when there are tabs within that line, such that each tab is counted as 1 column for the requested location rather than the actual columns it represents. To add to the inconsistency, it shows on the status line a column different than the one requested. i.e. the displayed column is actually correct regarding to the cursor position, but doesn't match the one requested.

cheers,
avih

[Avi Halachmi]

Logged In: YES
user_id=513930
Originator: YES

note: the above bug report relates to scite 1.71, tested on win32 (XP, SP2).

[Neil Hodgson]

Logged In: YES
user_id=12579
Originator: NO

The goto command is mainly for use by controlling programs and changing the meaning may break existing uses. Its also easier for the calling code to count characters rather than account for tab width which is dependent on settings.

[Avi Halachmi]

Logged In: YES
user_id=513930
Originator: YES

Well, you must admit that if you ask it to goto column 5 and when the document opens it shows on the status bar column 9, it's inconsistent.

I created a macro that opens scite from visual studio, if i need advanced editing features, and on many occasions the column is greater than the number of characters at that line, which causes scite to keep counting characters, sometimes ending few lines below the requested line (if there are empty lines after the requested one).

Even if it is used using both interpretations, i suggest at least to add a CLI flag to allow the caller to explicitly state a column rather than character count.

Thanks,
avih