-
-
Notifications
You must be signed in to change notification settings - Fork 82
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
[BUG] [Formatter] endtag and closing tag on same line are adding whitespace #167
Comments
Thanks for reporting! The issue is the But when we don't put trimmed in, we should not format it. The hard part is know which close tag I suppose the options for fixing djlint are - find a way to match start tags to close tags, or just ignore any blocktrans. |
Probably the best thing to do it just ignore {% blocktrans %} from the formatter and let users add it to their config file as a custom block if they want them formatted. @jayvdb @matthiask do you guys have an opinion on this? |
I thought a bit more about this, I think there are other cases where this is a problem, outside of the translate, as well. For example, unmatched html tags inside of template tags: {% if %}
<div>
{% endif %}
{% if %}
</div>
{% endif %} will format like this: {% if %}
<div>
{% endif %}
{% if %}
</div>
{% endif %} which is also wrong. Its probably just time to rewrite the indenter. Right now it is traversing the code linearly, and looking for tags to indent/unindent. We should probably use similar log to linter rule H025 and find tag pairs to indent instead. |
I opened #168 for folks using the |
We sometimes use {% if is_active %}
<li class="active">
{% else %}
<li>
{% endif %}
some content
</li> At one point you just have to admit defeat. Even with a rewritten parser, how would you indent the above so that both the If we accept the above as "code smell", we could say the better way to do this is to separate hierarchies of HTML and template tags when possible. <li{% if is_active %} class="active"{% endif %}>
some content
</li> |
I agree that the trimmed/non trimmed case is special enough to not be included in the default. For the li case - I haven't thought about it too hard to see where this breaks down, but if the rule is "indent one layer on li, and dedent on layer on else/endif" that would come pretty close, wouldn't it? The "some content" then would be flat against the left side, but the meaningful pieces would be closer to where you expect. I wonder if you could have two different parse trees to guess indentation, one for template tags and one for html. The html tree would be pretty straight forward, and the templatetag would be a mess of special cases. |
Thanks! This should be fixed in the latest commits, I'll publish a release soon. |
Things worked great for me on the newest version. Thanks! |
Nice, thanks for testing! |
System Info
Issue
Sometimes I'm seeing the formatter incorrect indent when two closing tags are right next to each other as shown in this diff:
You can see the
</p>
and everything after, right after the endblocktrans, should be dedented one levelHow To Reproduce
I see it every time I run the formatter against that specific template
The text was updated successfully, but these errors were encountered: