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

Macros and indentation level inheritance #821

Open
mataha opened this issue Jun 9, 2023 · 16 comments
Open

Macros and indentation level inheritance #821

mataha opened this issue Jun 9, 2023 · 16 comments

Comments

@mataha
Copy link
Contributor

mataha commented Jun 9, 2023

Say I have the following template:

{%- macro    code(var) -%}
if not "%VARIABLE%"=="{{ var }}" (
   echo {{ var }}
)
{%- endmacro code -%}

for %i in (a b c) do (
    {% call code("%i") ~%}
)

Is it possible, somehow, to inherit indentation level for the contents of the macro so that the text inside is properly spaced? Right now, the resulting template will look like so:

for %i in (a b c) do (
    if not "%VARIABLE%"=="%i" (
    echo %i
)
)

Which is obviously not what I'm trying to achieve (see here for my use-case coupled with a flabbergasting workaround).

@djc
Copy link
Owner

djc commented Jun 9, 2023

I don't think we offer control over this now, but it might be easy to change the behavior?

On the other hand, not sure if that's always desirable, and if not, how we would spell configuring it.

@mataha
Copy link
Contributor Author

mataha commented Jun 9, 2023

On the other hand, not sure if that's always desirable (...)

Definitely not.

(...) and if not, how we would spell configuring it.

My first thought would be {%+ - that is, it should be within whitespace control territory.

EDIT: forgot {%+ implies whitespace preservation - how about {%= as in "equal indent"?

@djc
Copy link
Owner

djc commented Jun 12, 2023

My first thought would be {%+ - that is, it should be within whitespace control territory.

EDIT: forgot {%+ implies whitespace preservation - how about {%= as in "equal indent"?

Sounds somewhat reasonable. So we only allow this for macro definitions, right?

@Kijewski @vallentin any thoughts?

@Kijewski
Copy link
Collaborator

Kijewski commented Jun 12, 2023

I can see why one would want this feature, not only in like in mataha's example, but in regular HTML output, too.

I guess this would be reasonably simple to implement, at least if the indentation level was user supplied by some means. I don't think it would be feasible to figure out the indentation level automatically at compile time.

Then Generator could have an indentation_stack: Vec<String> that is pushed to by calls to a macro, and popped from at the end of a macro. In Generator::visit_lit() the topmost indentation_stack gets used to prefix new lines.

@mataha
Copy link
Contributor Author

mataha commented Jun 13, 2023

What I've envisioned, though, is figuring out the indentation at compile time. Supplying it would require either some weird syntax ({#{1}+? I don't know), passing indent level through call (how?) or defining it globally in the template attribute (again, how?).

Generator does have access to whitespace in template here and here, right?

@djc
Copy link
Owner

djc commented Jun 13, 2023

We could do something like the whitespace after any newlines in the literal preceding the {% call %} node. That seems... a little magic and might not always have a very intuitive result but I suppose it would do the desired thing in a bunch of the common cases.

@mataha
Copy link
Contributor Author

mataha commented Jun 13, 2023

That solves my problem in full and - perhaps counterintuitively - is what I would expect.
Besides that, what other cases do you think can occur?

@djc
Copy link
Owner

djc commented Jun 13, 2023

Well, all of these could happen:

    {%= call foo(bar) %}
    {% if true %}{%= call foo(bar) %}{% endif %}
    {% if true %}{% else %} bloop {%= call foo(bar) %}{% endif %}

In particular, this last one I think would repeat bloop for every line that the macro produces.

@mataha
Copy link
Contributor Author

mataha commented Jun 13, 2023

How about make it either:

  • indent the contents with whitespace if the preceding characters after the last newline are all whitespace (i.e. match ^\s*; in the last case would not indent)
  • indent the contents with whitespace equal to the number of characters preceding a literal after the last newline (in the last case 7, but it would have to account for wide characters and possibly other corner cases...)

@djc
Copy link
Owner

djc commented Jun 14, 2023

@Kijewski any thoughts? Inventing a character sequence based on count seems way too magic. But I'm inclined to think the least magic behavior is that = just preserves the contents preceding the block after the last newline.

@Kijewski
Copy link
Collaborator

Kijewski commented Jun 14, 2023

I don't see any advantage in counting white space characters. If I use tabs, spaces, and some odd unicode characters to indent my code, then this exact indentation should be replicated.

In the end, I think everything between \n and {%= should be replicated. Maybe I want to wrap my text in a markdown blockquote >?

The only problem is if there are nodes {{expr}} / {%stmt%} before the {%=. I'd say, just make it a syntax error.

@djc
Copy link
Owner

djc commented Jun 14, 2023

I don't think we should make that a syntax error -- it would just only reproduce the whitespace after the {{ expr }} node: I specified the behavior as the "the literal preceding the {% call %}" node. So

 {% if true %}{% else %} bloop {%= call foo(bar) %}{% endif %}

would reproduce bloop on every line before the macro contents, because that's the literal before the {% call %} node.

@Kijewski
Copy link
Collaborator

Yeah, makes sense.

  • {% else %} bloop {%= bloop and
  • {% else -%} bloop {%=bloop

?

@djc
Copy link
Owner

djc commented Jun 14, 2023

Yup.

@mataha
Copy link
Contributor Author

mataha commented Jun 14, 2023

In the end, I think everything between \n and {%= should be replicated. Maybe I want to wrap my text in a markdown blockquote >?

That makes perfect sense. Just saying that at that point it's no longer "whitespace handling", of course.

@djc
Copy link
Owner

djc commented Jun 15, 2023

I think that's okay. Just needs good documentation.

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