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.
Axel
I'm generally on the "be an editor" front.
One algorithm for the serializer could be to minimize the textual diff
between the existing content in the file and the serialized output. In
particular for unchanged entities, that'd result in no change in the
text on disk.
Absolutely agree, that's my goal as well. So in the process of building the AST
I'm trying to identify which rules should be 1-1 between parse and serializer
(if parser does X, serializer reverts it), and which require AST annotation to
be written back (string quotes etc.)
I'm not sure what to do with escaping. Because in order to revert escaped char
in unicode I need to know that it was escaped. Which means either not
unescaping it when parsing, or annotating in AST somehow.
Yeah, my editor-writing self doesn't believe in parsing and serializing,
That's ok. Let's try to work around it and get an AST your editor-writing self
wants to work with :)
zb.
_______________________________________________
tools-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/tools-l10n
