Select statements are merged with a preceeding Jinja block

[gavlt]

A small select statement will be "optimistically" (or maybe "aggressively") merged onto closing Jinja brackets.

My use case here are dbt models against a Redshift database when we want to select a whole table from one schema into another and/or apply a (potentially new) partitioning which is managed by a dbt config block.

The resulting output feels a little compact to me. While sqlfmt doesn't necessarily share the complete Black philosophy, this style feels counter to readability and minimising git diffs (i.e. if in future I want to drop the config block it will impact the select statement also).

In #249 (comment) regarding preserving blank lines (like black) you made the following comment about this style/behaviour/request being popular, which I haven't been able to find any further reference to:

In other words, we'll allow 2 blank lines in between statements (e.g., between a {{ config }} block and select, which seems popular)

To Reproduce

{{
    config(
        dist="a_col",
        sort="another_col",
    )
}}

select * from {{ ref("another_model") }}

Actual behavior

{{
    config(
        dist="a_col",
        sort="another_col",
    )
}} select * from {{ ref("another_model") }}

Expected behavior
A blank line is preserved, or inserted, or the closing brackets are retained on the preceding line?

Additional detail
I see this behaviour is explained in the LineMerger:

# we can merge lines containing multiline jinja nodes iff:
# 1. the multiline node is on the first line (allow_multiline
#    is initialized to True)
# 2. the multiline node is on the second line and follows a
#    standalone operator

Is this change in style planned and/or on the roadmap or in flight, perhaps as part of #249 (which is intended for v0.15?)

[tconbeer]

Thanks for starting this discussion. I agree that this formatting with config is not good. This pattern (long config block followed by select *) is actually quite common in snapshot files, so it's something I've seen before, but punted on fixing.

The reason we merge like this is actually to make aliasing look nice:

-- we want this:
{{
    something(
    ...
    )
}} as my_field,

-- not this:
{{
    something(
    ...
    )
}}
as my_field,

And to treat jinja brackets similar to parens in chains of operators:

    # we do this
    left join
         order_type
         on {{
             sales_funnel_text_slugify(
                 "sheetload_sales_funnel_targets_matrix_source.order_type"
             )
         }} = {{ sales_funnel_text_slugify("order_type.order_type_name") }}

    # not this
    left join
         order_type
         on 
         {{
             sales_funnel_text_slugify(
                 "sheetload_sales_funnel_targets_matrix_source.order_type"
             )
         }}
         = {{ sales_funnel_text_slugify("order_type.order_type_name") }}

The good news is that I don't think there are any situations where we would want to merge a multiline jinja tag with a preceding or following token unless that token is an operator (e.g., +) or word operator (e.g., as, in) or comma. So there is definitely a path forward to improving this without special-casing too much.