Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What is a column or offset, exactly? #99

Closed
4 tasks done
wooorm opened this issue Feb 4, 2023 · 2 comments
Closed
4 tasks done

What is a column or offset, exactly? #99

wooorm opened this issue Feb 4, 2023 · 2 comments
Labels
🙅 no/wontfix This is not (enough of) an issue for this project 👎 phase/no Post cannot or will not be acted on

Comments

@wooorm
Copy link
Member

wooorm commented Feb 4, 2023

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:

  1. 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
  2. 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

?

@github-actions github-actions bot added 👋 phase/new Post is being triaged automatically 🤞 phase/open Post is being triaged manually and removed 👋 phase/new Post is being triaged automatically labels Feb 4, 2023
@wooorm
Copy link
Member Author

wooorm commented Feb 11, 2025

Closing as unresolved for now. I am leaning towards leaving which values to use undefined: allow different numbers in Rust vs in JS.

@wooorm wooorm closed this as not planned Won't fix, can't repro, duplicate, stale Feb 11, 2025
@wooorm wooorm added the 🙅 no/wontfix This is not (enough of) an issue for this project label Feb 11, 2025

This comment has been minimized.

@github-actions github-actions bot added 👎 phase/no Post cannot or will not be acted on and removed 🤞 phase/open Post is being triaged manually labels Feb 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🙅 no/wontfix This is not (enough of) an issue for this project 👎 phase/no Post cannot or will not be acted on
Development

No branches or pull requests

1 participant