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
I searched issues and couldn’t find anything (or linked relevant results below)
Problem
…or are they supposed to be vague and should we reflect that?
For ASCII characters, such info is pretty clear.
But once you get to other unicode characters, taking emoji as a well-known
example, it gets complex.
And, unist is designed for other programming languages too, practically
now with Rust, we may need to choose how to represent this across languages.
There are two main ways that positional info like this is used:
to access the source string: if there is something appearing from 1000 to 1002, a user will want to do doc.slice(1000, 1002)
to access that thing.
In Rust, 1000 and 1002, in an example of &doc[1000..1002],
will yield a different result
to point a code editor to such a thing, for warnings and such, so that
the squigly lines, or “jump to” are correct
To make the first easy and fast, it makes a lot of sense to use the positions
that are based on how the host language stores strings.
But that means markdown-rs and micromark will yield different results.
Quickly checking VS Code, injecting 👨👩👧👦 into the document, seems to increment
by 7, which equals [...'👨👩👧👦'].length.
So that’s different from what markdown-rs and micromark use.
We can also be vague about this here in the spec, and replace the section added
in 49032b9 to reflect that.
Or we could adhere to that?
Solution
a) Make vague
b) make everything consistent
Alternatives
?
The text was updated successfully, but these errors were encountered:
Initial checklist
Problem
…or are they supposed to be vague and should we reflect that?
For ASCII characters, such info is pretty clear.
But once you get to other unicode characters, taking emoji as a well-known
example, it gets complex.
And, unist is designed for other programming languages too, practically
now with Rust, we may need to choose how to represent this across languages.
There are two main ways that positional info like this is used:
1000
to1002
, a user will want to dodoc.slice(1000, 1002)
to access that thing.
In Rust,
1000
and1002
, in an example of&doc[1000..1002]
,will yield a different result
the squigly lines, or “jump to” are correct
To make the first easy and fast, it makes a lot of sense to use the positions
that are based on how the host language stores strings.
But that means
markdown-rs
andmicromark
will yield different results.Quickly checking VS Code, injecting
👨👩👧👦
into the document, seems to incrementby
7
, which equals[...'👨👩👧👦'].length
.So that’s different from what
markdown-rs
andmicromark
use.We can also be vague about this here in the spec, and replace the section added
in 49032b9 to reflect that.
Or we could adhere to that?
Solution
Alternatives
?
The text was updated successfully, but these errors were encountered: