Byte position is a worse solution because it's worse UX for the user.
Given a byte position in a file, how would a human navigate there? Where's byte offset 6 in "おはようございます"?
The argument about big files is also pretty weak. Big files are the exception, not the rule. And line/col values happen on error paths, not the happy path. So processing time is largely irrelevant.
AND, this extra processing would be done offline anyway, since the parser always knows the line/col because it has to process the whole file every time regardless.
We use line/col instead of byte position for good reason: it just plain works better for our use cases.
A human could navigate by invoking the GoTo command and pasting the number, not harder than finding the 8th char in a foreign script (is the 2nd char in your text a single vertical line or does it include the next symbol?)
6 comments
[ 4.3 ms ] story [ 14.1 ms ] threadGiven a byte position in a file, how would a human navigate there? Where's byte offset 6 in "おはようございます"?
The argument about big files is also pretty weak. Big files are the exception, not the rule. And line/col values happen on error paths, not the happy path. So processing time is largely irrelevant.
AND, this extra processing would be done offline anyway, since the parser always knows the line/col because it has to process the whole file every time regardless.
We use line/col instead of byte position for good reason: it just plain works better for our use cases.
But for people looking at files with text editors?