Ability to add line continuations in multi-line contexts

[Xophmeister]

Is your feature request related to a problem? Please describe.
In some languages (e.g., Python, Bash), multi-line contexts require a line continuation character; usually an escaped newline.

I don't believe -- but I'm not certain! -- that it's possible to distinguish between a single-line and multi-line context, in the query language. That is, in the sense of performing different actions in different contexts. Therefore, line continuations can't be inserted as though they were delimiters, because they'd be inserted in all contexts.

Describe the solution you'd like
As this would apply to the source as a whole, perhaps a new directive:

(#multiline! STRING)

The default would be (#multiline! "\n"). However, this could be overridden to something like (#multiline! " \\\n") -- or whatever the language's escape character is -- when needed.

Any newlines that are added by Topiary in a multi-line context will use this STRING, rather than a simple \n.

Describe alternatives you've considered
One could assume the programmer knew what they were doing and thus look for manually added line continuation nodes. Then queries could be written that target these characters: if they exist, we're in a multi-line context; otherwise, single-line.

My gut feeling is that this may incorrectly target non-line continuation nodes. However, even if that's not the case, it would double the number of queries required (i.e., an explicit multi-line and single-line version, for each).

[Xophmeister]

A rule that explicitly targets the line-continuation and appends a hardline was suggested, so multi-line Bash commands preserve their formatting. i.e.,:

(command
  "\\" @append_hardline
)

Unfortunately, the Bash grammar rejects this query outright with an Invalid node type error 😞

[Niols]

I'm actually quite curious to see how that will unfold. I don't know about bash, but in POSIX Shell, the line continuation is not handled in the parser but in the lexer. If the tree-sitter grammar follows the official one, I suppose it would not appear there. (Again, bash is very much not POSIX Shell so it might be doing its own thing there.)

[Xophmeister]

On further thought, having this apply to the whole source will be too general; even if it's limited to just softlines. For example, I've specified the following queries to format Bash compound statements:

(compound_statement
  .
  "{" @append_spaced_softline @append_indent_start
)

(compound_statement
  "}" @prepend_spaced_softline @prepend_indent_end
  .
)

With the proposal in the OP issue, that would format a multi-line compound statement like so:

{ \
  whatever \
}

That's neither what we want, nor -- in this case -- is it valid, as this code is equivalent to { whatever } which is syntactically incorrect.

Perhaps a construct more like this, where specific nodes are tagged as requiring line continuations would be better:

; Set the continuation string for softlines globally...
(#line-continuation! " \\")

; ...but only apply it to tagged nodes
[
  (some)
  (node)
  (types)
] @require_line_continuation

Or perhaps delimited softlines (#175) would serve both cases, where the line continuation is the delimiter.

[Xophmeister]

See #205 for a possible solution.

[nbacquey]

Does #354 solve this issue, with (@append_delimiter) and (#multi_line_only!)?

[Xophmeister]

Does #354 solve this issue, with (@append_delimiter) and (#multi_line_only!)?

In principle, yes 🎉 It's a little bit fiddly, for line continuations, because you have to @append_delimiter at every expected line-break (apart from the last one). It can be done, though. For example, these rules added to the Bash rules:

(command
  (_) @append_delimiter @append_spaced_softline
  .
  (_)

  (#delimiter! " \\")
  (#multi_line_only!)
)

(command
  .
  (_) @append_indent_start
) @append_indent_end

...correctly produce this output:

command \
  --option1 \
  --option2
command --option1 --option2