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

Role syntax for option parsing? #69

Open
chrisjsewell opened this issue Feb 20, 2020 · 2 comments
Open

Role syntax for option parsing? #69

chrisjsewell opened this issue Feb 20, 2020 · 2 comments
Labels
discussion no fixed close condition syntax descisions on syntax formats

Comments

@chrisjsewell
Copy link
Member

chrisjsewell commented Feb 20, 2020

With the standard docutils syntax/parser, there is no way to parse options to role functions :name:`content` . However, in the actual role function signature it does accept an options keyword:

    def __call__(self, role, rawtext, text, lineno, inliner, options={}, content=[]):
        pass

Therefore, it would be conceivable to write myst specific roles that actually did something with these options. No idea what a good syntax would be though.

@chrisjsewell chrisjsewell added syntax descisions on syntax formats discussion no fixed close condition labels Feb 20, 2020
@choldgraf
Copy link
Member

I think it's a feature that'd be really useful to have, but that we should avoid for the time being because if we ever implemented it, then rST documents and MyST documents would have a different feature set from one another. If, eventually, this markup language became popular enough, then it may be worth breaking that strict requirement in order to add new features, but my feeling is we should hold off on this for now. What do you think?

That said, some syntax ides :-)

  • `{role}`content [option option key=val key="val w spaces"]`
    
  • {role}`content <option option key=val key="val w spaces">` 
    
    this would let us mimic behavior for things like <> syntax as link targets

@chrisjsewell
Copy link
Member Author

we should avoid for the time being

Yeh absolutely. I just put this here for completion

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion no fixed close condition syntax descisions on syntax formats
Projects
None yet
Development

No branches or pull requests

2 participants