Skip to content
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

Make all BlockParser and InlineParser APIs public #600

Open
matthew-carroll opened this issue Mar 23, 2024 · 2 comments
Open

Make all BlockParser and InlineParser APIs public #600

matthew-carroll opened this issue Mar 23, 2024 · 2 comments

Comments

@matthew-carroll
Copy link

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 own InlineSyntax.

Any API that's needed by any BlockSyntax or InlineSyntax 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:

var runLength = match.group(0)!.length;
    var matchStart = parser.pos;
    var matchEnd = parser.pos + runLength;
    var text = Text(parser.source.substring(matchStart, matchEnd));
    if (!requiresDelimiterRun) {
      parser._pushDelimiter(SimpleDelimiter(
          node: text,
          length: runLength,
          char: parser.source.codeUnitAt(matchStart),
          canOpen: true,
          canClose: false,
          syntax: this,
          endPos: matchEnd));
      parser.addNode(text);
      return true;
    }

    var delimiterRun = DelimiterRun.tryParse(parser, matchStart, matchEnd, syntax: this, node: text, allowIntraWord: allowIntraWord);
    if (delimiterRun != null) {
      parser._pushDelimiter(delimiterRun);
      parser.addNode(text);
      return true;
    } else {
      parser.advanceBy(runLength);
      return false;
    }

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.

@srawlins
Copy link
Member

Yeah I think that's fair.

@MiniSuperDev
Copy link

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants