Open h4kuy4 opened 1 year ago
What errors do you expect to have? And how do you want to handle them outside?
The current assumption is that the parser should work on any user input, and that plugins should handle their own errors. If some errors can be handled better from outside, we should probably add methods like try_parse
and try_render
alongside of parse
and render
.
Like highlight with treesitter, we may use tree-sitter-loader
to load parser of tree sitter at runtime(we need cloned the parser's repositories previously and it is every single repository for each language).
and it is also load parser with a string called scope
not just the name of language, in my test code, I use a match
to handle this like image below. But if make it as a plugin an public it, I have to add all of the pairs into the match
.
So it may happen that parsers for some languages not found. I think this type of error may need to pass to the outside, and them we can decide to print a log and ignore the error or panic the program.
I'd could also vote for returning a Result
from parse
. I get that parsing Markdown cannot fail according to the spec. But the same is likely true for all the kinds of plugins people are writing. I found myself wanting to return an error to the user for some extensions I'm adding to Markdown.
I think there's ways around this (maybe walking the AST after parsing and looking for markers that an error occurred in the custom Nodes?) but just wanted to flag that I also ran into this.
I found myself wanting to return an error to the user for some extensions I'm adding to Markdown.
Okay, I've added function try_parse()
(which propagates errors) along with existing parse()
(which doesn't).
See https://github.com/rlidwka/markdown-it.rs/pull/19 for details.
While I'm trying to write a plugin to highlight the code with tree sitter, I found that I can't pass the error to the outside. I suggest that use
Resut
to pack the return value instead of use return value directly.