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
Get image/link title offset range. #441
Comments
Hi. Apologies for the late response on this. It seems you have a solid understanding of the library, so there's little I can tell you that you haven't figured out already. For my understanding: is it correct that you are highlighting markdown source? I believe currently the only solution for "owned" strings like titles -- these could generally be borrowed as well, I think? If not, this may be something I would have to look into -- is the one you outlined above. The way to solve this from a library perspective is to introduce additional events for the 'components' of a link, but that may not be an improvement in terms of ease-of-use or performance for cases where you don't need these source mappings. I will leave this issue open for others to comment on whether they would need something like this in the library. |
I agree - if titles were Borrowed then I could calculate offset :) I'll fork and check if this is viable. |
I've just bumped into a similar need. I'm trying to inform a vim syntax highlighter based on this (see vim-commonmark) and ran into trouble with links. Inline links are easy, but Reference links for example don't have any good information. about where the link ends in the source. The range returned for the start event is a single byte. Additionally it takes a lot of guess work matching strings and lengths to figure out where the delimiters for Inline links are. An option to return more event info with these positions would be quite useful. |
Fixes rust-lang#110111 This bug, and the workaround in this commit, is closely linked to [pulldown-cmark/pulldown-cmark#441], getting offsets of link components. In particular, pulldown-cmark doesn't provide the offsets of the contents of a link. To work around this, rustdoc parser parts of a link definition itself. [pulldown-cmark/pulldown-cmark#441]: pulldown-cmark/pulldown-cmark#441
…d-syntax, r=GuillaumeGomez,fmease rustdoc: get unnormalized link destination for suggestions Fixes rust-lang#110111 This bug, and the workaround in this PR, is closely linked to [pulldown-cmark/pulldown-cmark#441], getting offsets of link components. In particular, pulldown-cmark doesn't provide the offsets of the contents of a link. To work around this, rustdoc parser parts of a link definition itself. [pulldown-cmark/pulldown-cmark#441]: pulldown-cmark/pulldown-cmark#441
Fixes rust-lang#110111 This bug, and the workaround in this commit, is closely linked to [pulldown-cmark/pulldown-cmark#441], getting offsets of link components. In particular, pulldown-cmark doesn't provide the offsets of the contents of a link. To work around this, rustdoc parser parts of a link definition itself. [pulldown-cmark/pulldown-cmark#441]: pulldown-cmark/pulldown-cmark#441
Hello, thank you for your fantastic project.
I'm writing a small language with markdown support, and I wanted to add syntax highlighting for Neovim.
Therefore I have to parse markdown.
Pulldown-cmark
works great in most cases, because you provide me access to offsets viainto_offset_iter()
.However, this gets me a range for the whole tag. For example:
This would give me
(0..112)
- the range for the whole text.There are cases when I need to process or highlight only part, for example, title, therefore I need to somehow calculate the range for both src, title, and of course, the body (displayed text, alt text, etc.).
The third one is easy, It lives under different event. The first one is also quite interesting and possible. Because it's under
CowStr::Borrowed
- I can perform the offset calculation (by subtracting pointers to the slice, which is, in fact, continuous memory. Note that I assume nobody made any owned event and everything is referencing to the original single source).However, the title is under
CowStr::Inlined
- which means my only solution, for now, is to perform a classic search to find where exactly lives. However, even this can be tricky - what if the title has the same content as for example link or alt text?Anyway - do you see here any possible good solution?
The text was updated successfully, but these errors were encountered: