Config file to ignore some block tags

[symroe]

Hello. Firstly thanks for the library, we're trying it out on our projects and really like it so far.

We have one small problem though. We use a markdown block filter, where the content of the block is parsed as markdown. This means initial space (as djhtml adds) is parsed as a blockquote.

I know we can use the fmt control comments, but ideally we'd be able to automatically ignore anything inside {% filter markdown %}.

I was going to raise a PR for this, but I realise that this is a very specific case. Rather than adding exemptions ad-hoc, it might be better to allow configuring blocks to be excluded by the user / project.

Alternatively, it might be a good idea to slip formatting inside filter blocks altogether - but I don't know enough about how they're used in other projects to know if this would be a good idea.

I'd be interested to hear your thoughts on this, and would be happy to submit a PR once we've worked out a good solution.

[JaapJoris]

Hi there, and thanks for your willingness to contribute! We have discussed introducing a config file in the past, see the comments on issue #16.

My preferred solution would be to have a config file called setup.cfg (because it can be parsed with configparser without introducing extra dependencies) that looks something like this:

[djhtml]
tabwidth = 4
ignore_tags = filter comment verbatim raw

However, this implies that all {% filter %} tags will be ignored, not just the {% filter markdown %} tag. Do you think this is too limiting? Alternatively, we could allow the config file to specify individual opening and closing tokens, but I'm afraid that would be more complicated.

In any case, I will be happy work with you on a PR that introduces a configuration file to DjHTML 🙏

[symroe]

My preferred solution would be to have a config file called setup.cfg (because it can be parsed with configparser without introducing extra dependencies) that looks something like this:

Yes, I saw that comment on #16 — it seems like it would be a useful thing to do for more than just this case.

I think the "on trend" thing to do would be to use a section in a pyproject.toml file, but I understand your point about not introducing extra dependencies.

However, this implies that all {% filter %} tags will be ignored, not just the {% filter markdown %} tag. Do you think this is too limiting? Alternatively, we could allow the config file to specify individual opening and closing tokens, but I'm afraid that would be more complicated.

Well, for our use-case, we'd be happy ignoring all filter tags, but I don't know if this is the case for other users. It seems to make sense to me that the content of a filter tag will get parsed elsewhere, and it's not unreasonable to exclude all content on that bases.

How much more complex would it be to expand the scope of work to use the full tokens?

[JaapJoris]

How much more complex would it be to expand the scope of work to use the full tokens?

We would have to come up with a way to specify the opening and closing tags in the configuration file. Something like:

[djhtml]
ignore = "Ignore all blocks that start with {% filter markdown %} and end with {% endfilter %}"

But I don't think configparser is suited for this kind of "advanced" configuration. How could this look in pyproject.toml syntax?

[symroe]

Ah yes, I see the config syntax might be tricky, but I expect this problem would exist in toml too - we don't want to make our own DSL inside an existing config syntax, I don't think.

What about simply using startswith for the opening token, and then f"end{token.split(' ')[0]}" (or similar) for matching the end token?

This would allow

[djhtml]
tabwidth = 4
ignore_tags = 
    "filter markdown"
    comment
    verbatim
    raw

But I appreciate this might also be too complex, especially if config parser required the quoting.

MVP is absolutely your initial suggestion!

[JaapJoris]

@symroe, are you still willing and able to create a PR with your suggested changes? Is there anything you need from my side to assist you? Or have you perhaps moved on to other stuff (which is totally fine, of course)?

[symroe]

Sorry, life has got in the way. I'll try to have a crack this weekend 👍 Thanks for the reminder