-
Notifications
You must be signed in to change notification settings - Fork 61
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
Does this help with automatically figuring out highlight? #348
Comments
Yes. I have a bit more time now because I finished my thesis, so I was looking into plugging this into the plugin. I was thinking of making a prototype using the neovim lua highlighting facilities, I don't know if that will be generally usable but it will be a start. |
@alok Yes it does! It has some caveats because it's for the CommonMark parser only, not the old Pandoc parser, but it's progress. This issue is mostly a duplicate of #300 and #327. We've actually been tinkering with this for a while, and we were actually one of the ones pushing for that feature. It's exciting to see it finally landing. |
Indeed! The only worry I have for now is the speed of the parsing step itself -- @alerque, we tried commonmark-hs, right? It wasn't as fast as the rust library if I remember correctly. |
At the time I tried the Haskel library that I assume the Pandoc app is now using it was at least an order of magnitude slower that the Rust based parser I was experimenting with. It's really interesting to have truly Pandoc generated AST mappings, but if this is limited to Common Mark anyway it probably isn't our fastest option by a long shot. |
I think that the fact that it gives a full map of the source is excellent, though. We can use that information to cache more intelligently: for example, only redraw the paragraphs that were just edited--in that case we can compensate for the slow parsing with feeding pandoc less data. |
jgm/pandoc#4565
The text was updated successfully, but these errors were encountered: