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

"Blacklist" directives which are not in docutils? #15

Open
rduivenvoorde opened this issue Nov 1, 2019 · 1 comment
Open

"Blacklist" directives which are not in docutils? #15

rduivenvoorde opened this issue Nov 1, 2019 · 1 comment

Comments

@rduivenvoorde
Copy link

rduivenvoorde commented Nov 1, 2019

Hi, thanks for the plugin!

I'm trying it out to check if I can make it easier for people to write some documentation (written for Sphinx in rst)..
Looks promissing!

Opening one of the rst files I get an error about the 'toctree' Sphinx directive... :

Screenshot-20191101130328-801x665

If I'm right the issue here is that this is a sphinx directive and not a docutils directive?
Which is reasonable.
So I'm coining the idea here to have some list of directives to be ignored during parsing. So the plugin should "preflight" the text and remove the directives that are on that 'blacklist'.
Not sure if this is easy to do, or there are other ways to do this? Is there something like that in docutils maybe?

In the Preview-window one could either ignore it and show nothing, OR add some small message "ignored directive" or so?

@bittner
Copy link
Owner

bittner commented Nov 3, 2019

The plugin is simply running a conversion to HTML. Hence, if anything goes wrong in the conversion this typically produces output in HTML that looks like above in your screenshot.

I'm not sure if it makes sense to hold a blacklist of directives. I think the conversion topic is too complex. However, I agree this could be made more robust.

Currently, any result is directly stored in the html variable and then used to update the HTML view. This is obviously "wrong" or at least "too simple".

It would be nice to keep the content in the last working state (not always trivial; what if the very first compile of the source file fails when opening the document?) and show an appropriate, helpful error message in the status bar or footer of the editor window. In this context it would also be helpful to know whether publish_parts can yield some error status or something similar.

Do you happen to know? A PR is always welcome!

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

2 participants