Comments (8)
Ah right got it. Thanks for the pointers. The JS parser may make things a bit more complicated I guess if you want to support arbitrary errors - String
kind of make sense there.
I'll start with parsing the errors myself for now. Happy to report back later how that goes.
Thanks again!
from markdown-rs.
Welcome @begleynk!
Thanks for sharing your idea!
To preface, markdown-rs and the closely related unified js ecosystem, follow a variation on the Unix philosophy:
- Write programs that do one thing and do it well.
- Write programs to work together.
- Write programs to handle
text streamsSyntax Trees, because that is a universal interface.
This module focuses on parsing valid markdown and mdx prioritizing (in order): following the CommonMark and MDX standards, being extensible to support many different use cases, and being fast and efficient.
To answer your questions:
- Is there interest in more authoring experience tools to offer localized and descriptive recommendations? Yes! Packages are welcome to wrap markdown-rs with this functionality
- Should that functionality live in the core parser package? No, the weight of a second parser to guess at intent and localizing messages goes outside the scope of markdown-rs. They would be a better fit for another module, likely a language server module like https://github.com/mdx-js/mdx-analyzer
from markdown-rs.
Thanks for the details!
Just to clarify - I agree that putting the rendering logic for the specific kind of error messages I want to show doesn't belong into markdown-rs
.
What I'm really asking about is if you'd be interested in changing the return type for this function (and the _html
equivalent) from Result<Node, String>
to a more structured Result<Node, Error>
, where the Error
type would have more details about the error.
Right now the information about where exactly the error came from becomes harder to gather programmatically since it's a String
,
Then the user would be able to customize the error presentation, wrapping the library for their own use case, and you could still have the Display
implementation to give the current error message.
Does that make sense?
from markdown-rs.
to a more structured
Result<Node, Error>
, where the Error type would have more details about the error.
The string is already pretty structured, line, column, reason. What more do you need?
I think you should already be able to do what you want with that info. Perhaps it can be a “prettier” result, but what can be done with errors should be the same?
The reason I started simple is that this project is no_std + alloc, so it’s very minimal. And errors don’t exist in markdown itself, only in MDX.
So pulling in a more complex project for errors will be unused by many users.
from markdown-rs.
The string is already pretty structured, line, column, reason. What more do you need?
I was hoping that e.g. get the starting position of the offending tag directly for the purpose of creating the custom error I described above. A workaround is using regex to pull them out of the error string.
I'm happy to go with that workaround for now if you feel there isn't much use for this outside our admittedly niche use case.
We just wanted to customize the error quite heavily so we were hoping to do this without resorting to regex, and figured this may be something others would be interested in.
Really impressed with the library. Thank you for creating and maintaining it ❤️
from markdown-rs.
<3
Well, you don’t need regex, this whole project doesn’t, should be a relatively small parse ;)
What info would you want? Is there more you’d want? Is a small struct
with a point
and reason
enough?
from markdown-rs.
Well, you don’t need regex, this whole project doesn’t, should be a relatively small parse ;)
Fair point ;) And there's only 6 distinct error messages by my count in to_mdast.rs
, so it's not a lot of work.
What info would you want? Is there more you’d want? Is a small struct with a point and reason enough?
That would be amazing. If possible it would be super useful to also have the end point of the tag being referenced, not just the start. But a brief glance at the code shows that info might not be available where those errors are generated?
Also some errors also reference two different tags (i.e. the open and close tag) - it would be great to have positions of both (hence my suggestion for the enum to describe the different cases).
But feel free to close this issue, unless you feel there's value in keeping it around.
from markdown-rs.
There are also errors thrown from the JavaScript parser that is passed in. As that parser is arbitrary, those errors are also arbitrary.
to_mdast
is one part, there are also many “parse errors”, see for example
markdown-rs/tests/mdx_jsx_flow.rs
Line 132 in 60db8e5
I’m open to a PR that uses a simple structure, reason
and point
.
If and when you work then you can investigate whether positions, and actually two positions, makes sense. I think it’s only very few cases where that info exists.
from markdown-rs.
Related Issues (20)
- Compile mdast to html HOT 4
- Expose a way to compile mdast to html HOT 1
- crate::Options is not `Sync` HOT 6
- Convert HTML into Markdown HOT 2
- Would `to_mdast()` return variants of `mdast::Node` other than `mdast::Node::Root`? HOT 1
- Whitespace text nodes cannot appear as a child of <tr>
- HTML in markdown HOT 2
- GFM strikethrough causes nested attention sequences to be considered just text data HOT 3
- Option to only produce tags for explicit markdown HOT 2
- Inlines in Image HOT 3
- Stronger types HOT 5
- Allow both gfm (for tables) and allow embedding HTML with allow_dangerous_html HOT 1
- Field-variants rather than tuple-variants for Block, Span HOT 1
- log spamming
- API for creating extensions? HOT 1
- How to get math working HOT 4
- Get marker delimitation HOT 4
- to_html_with_options isn't found HOT 3
- Whitelist anchor HTML tags? HOT 8
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from markdown-rs.