Open matthew-carroll opened 8 months ago
Yeah I think that's fair.
@srawlins Hi, I think you should also expose the utils, patterns etc to make more easy to create custom extensions.
For example I create a extension similar to FencedCodeBlockSyntax
with support for file name and highlight lines.
It is based on the FencedCodeBlockSyntax
and because it use a a lot of private utils, I reweite this utils and patterns used in my project.
If all of you use to create the built in extension is public it will be more simple to create extensions and we can use the built it extensions as a examples and use all code that their use, specially in cases when we use mostly your same implementation but only need to add a little custom logic.
Thanks
I'm trying to build a solution to #599 in my own package. To do that, I'm trying to define my own
InlineSyntax
, which needs to inspect the_delimiterStack
. But the_delimiterStack
is private, so I can't access it from my package, preventing me from building my ownInlineSyntax
.Any API that's needed by any
BlockSyntax
orInlineSyntax
should be public, so that the developers outside of this package don't become second-class citizens with respect to what they're allowed to access.Here's a snippet from
TagSyntax
within this package:Notice that it would be impossible for this same class to be defined from outside the package.
There's no reason to hide things from the outside world. This is a parsing package - if something is relevant for parsing, it should be public.