You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using the lc attribute of CommentedMap and CommentedSeq enables you to get the line index and starting column of a given key/value/item. So far so good. However, it is hard to figure out where the object in question ends.
Consider the following input:
foo: stringbar: "string"
Both of these start a column 5 on their respective line and their parsed form is string (6 characters). But the first line is 2 characters shorter than the second due to the quotes.
This makes it hard to compute ranges of values for tokens. As I am writing a language server (LSP) for a YAML based format, I need to report diagnostics (linting) via ranges - that is, start and end position, such that the editor knows exactly where to put its error markers.
The underlying tokens already have a start and and end marker (at least, during the token/parse phrase), so for trivial cases the data is already available just not exposed. I am less sure how to handle values like objects and lists. But for starters, just having exact start + end position on basic types like strings, bool, int/float, etc. would be a great help. :)
The text was updated successfully, but these errors were encountered:
Using the
lc
attribute ofCommentedMap
andCommentedSeq
enables you to get the line index and starting column of a given key/value/item. So far so good. However, it is hard to figure out where the object in question ends.Consider the following input:
Both of these start a
column
5 on their respective line and their parsed form isstring
(6 characters). But the first line is 2 characters shorter than the second due to the quotes.This makes it hard to compute ranges of values for tokens. As I am writing a language server (LSP) for a YAML based format, I need to report diagnostics (linting) via ranges - that is, start and end position, such that the editor knows exactly where to put its error markers.
The underlying tokens already have a start and and end marker (at least, during the token/parse phrase), so for trivial cases the data is already available just not exposed. I am less sure how to handle values like objects and lists. But for starters, just having exact start + end position on basic types like strings, bool, int/float, etc. would be a great help. :)
The text was updated successfully, but these errors were encountered: