Not really. It is worth looking at Scintilla doc (or Scintilla.iface) to see the API to
Scintilla.
Relevant line in the iface file:
# Returns the position of the caret.
get position GetCurrentPos=2008(,)
At the start of the file:
## Each feature is defined by a line starting with fun, get, set, val or evt.
## get -> a property get function
## Types:
## position -> integer position in a document
## Line numbers and positions start at 0.
So it is not an "absolute column number" but the position of the caret in the document in
terms of character count.
There are also functions to get the line corresponding to a position:
local endLine = editor:LineFromPosition(endPos)
and the reverse (position of the start of the line):
local lineStartPos = editor:PositionFromLine(endLine)
You can have also the position of the end of the line:
local lineEndPos = editor.LineEndPosition[lineNb]
(extracted from my SciTEStartup.lua)
http://bazaar.launchpad.net/~philho/+junk/SciTESettings/view/head:/SciTEStartup.lua
--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --
It is worth looking at Scintilla doc (or Scintilla.iface) to see the API to Scintilla.
So it is not an "absolute column number" but the position of the caret in the document interms of character count.
For me (but I am not a native English speaker), a column position is a position in a line.
A relative column position might mean n chars to the left or the right from a given
position (eg. caret position), an absolute column position would be a position from the
start of the line.
That's what GetColumn returns, for example.
BTW, Neil, I think the line:
get int GetLineEndPosition=2136(int line,)
should be:
get position GetLineEndPosition=2136(int line,)
So for drawing indicator on Line 3 at position 5 with length 10, this needs to be done:
editor:GotoLine(3)
I agree with Philippe (and I'm a native English speaker). A column
position refers to position in a single line. The "document position
in terms of character count" is the position in the whole file.
So if your document has 4000 characters, and the last line of that
document has 56 characters, then the last character in the document
has file position (or document position) 3999, but column position 55
(in both cases assuming 0-based indexing).
Earlier, zetah wrote:
> Positioning seem to be in absolute column number
> and not relative to specific line
In English, this is a contradictory statement. By definition, columns
only refer to positions within a line. (Or you could say a column
position is a position on *all* lines, in the same way that in Excel,
column B is the second column in the sheet, and referring to that
column without referring to a specific row means the union of B1, B2,
B3, B4, etc.)
John
Earlier, zetah wrote:> Positioning seem to be in absolute column number
> and not relative to specific lineIn English, this is a contradictory statement. By definition, columns
only refer to positions within a line. (Or you could say a column
position is a position on *all* lines, in the same way that in Excel,
column B is the second column in the sheet, and referring to that
column without referring to a specific row means the union of B1, B2,
B3, B4, etc.)
Hm. I haven't had to deal with Unicode much, and I still primarily
use Python 2, so bytes and characters are almost the same thing for
me. But I think I prefer the concept that "characters" are
human-readable characters, no matter how many bytes they require to
represent.
John
Precise vocabulary is needed to communicate, particularly in the technical field. :-)
> I hope that if someone browse Internet for this reference and got
> point here it will be clear that SciTE/Scintilla does not position by line and column, as
> beginner would expect
Unlike some other editors, Scintilla has a continuous buffer (with a gap). Beside some
optimizations, it sees lines only by detecting line ending chars. It doesn't store data in
lines, but it offers an API to convert between position and line.
A line/column system can have issues, as it is not a grid, lines have different numbers of
columns. There is no perfect system...
> OTOH, there is issue also with your definition of character count, which should be byte
> count, as "editor:IndicatorFillRange(5, 10)" marks different string in ascii text and in
> 2byte UTF-8 string.
Yes, I misused the vocabulary here. It depends on the encoding of the buffer: in the
native code page (ISO-8859-1 or more probably CP-1252 for me), an accented char like é is
one byte. In an UTF-8 or UTF-16 encoding, it is two bytes (I think internally it uses
DBCS). A char like ♥ uses three bytes/positions, and can't be displayed with my local code
page. Etc.
> BTW, Neil, I think the line:
>
> get int GetLineEndPosition=2136(int line,)
>
> should be:
>
> get position GetLineEndPosition=2136(int line,)
OK, committed.
Neil