On Sunday, May 3, 2015 at 4:01:17 AM UTC-4, Axel Hecht wrote: > On 5/2/15 3:07 AM, Zibi Braniecki wrote: > > On Friday, May 1, 2015 at 3:47:57 PM UTC-4, Axel Hecht wrote: > >> Maybe look at what treehugger does via setAnnotation? > >> https://github.com/ajaxorg/treehugger/blob/master/lib/treehugger/tree.js > > Interesting. So you think it would be better to give you col/line instead > > of pos? I like to think of the source as a long string, and avoid building > > any piece as white-space driven, so my idea would be rather to give you > > pos.start and pos.end. > > > > Would that work? > In my experience, machines want the global offset, humans don't. Text > editors are "both", at least ace splits the doc into lines. > > Which is a lengthy way of saying "depends on the use case", and the > optimizations for it.
True, my thinking is that the editor will format a source string into rows and cols, so it should be able to calculate it. Parser doesn't store row/cols, parser stores position in a source string, so it's easier for the parser to annotate it. zb. _______________________________________________ tools-l10n mailing list [email protected] https://lists.mozilla.org/listinfo/tools-l10n
