feat: Text lines within Statement Blocks

[TekWizely]

Adds ability to insert text lines within a statement block.

• Default delimiter is '% ' (note trailing space)
• Lines within a statement block starting with '% ' are treated as text
• Delimiter is configurable via:
  • --text-delim | --txt-delim CLI options
  • BASH_TPL_TEXT_DELIM environment variable
  • TEXT | TXT property in DELIMS directives

docs: Adds docs for new text line test: Adds tests for new text line test: Fleshes out script_block.tpl test docs: Tries to better-clarify tag defaults docs: Replace previous usages of "text tags" with "standard tags" docs: Fixes table format per IntelliJ warnings refactor: Moves debug info into function

BREAKING CHANGE: Keeps searching for 1st indented line within statement blocks, and uses it to define auto-indent-correction strategy. Should provide more consistent behavior to otherwise well-indented scripts in the case where the first line of the block happens to not be indented.

[TekWizely]

@flaix If you're still using Bash-TPL, I'd love to get a review on this PR and maybe your thoughts on this feature in general?

[flaix]

Hi @TekWizely, I am terribly sorry, I did not see this. I noticed there was a PR, but did not see your comment.

I do not have the use case of having to close statement blocks just for one or two lines. So the feature is not something I had been missing. I only use single statement lines between outputs, or statement blocks with only statements, no output.

I just ran the new version against my template file again. The only change is that for me the indentation is now, well, incorrect. This is due to your "fix" for non-indented first lines. Was this an often occurring problem? For me the first line in a statement block is almost never indented. Because, well, it shouldn't be. The statement blocks form the generation script and that starts at indent 0. Any deeper indentation would be explicitly added by me. So with my templates the change has an adverse effect. I am not quote sure I understood the necessity for it from your example.

This is an example block from my template.

%

if [[ -n "${OUPUT_FILE}" ]]; then
    exec > "${OUPUT_FILE}"
fi

%

This used to produce a correctly indented script, as I had intended. Now, all three lines are on the same indentation level: zero.

if [[ -n "${OUPUT_FILE}" ]]; then
exec > "${OUPUT_FILE}"
fi

[TekWizely]

Hey @flaix thanks for chiming in !

You know, I didn't think of "no indentation" as an active choice, but more as an oversight or a "i need this one line to specifically be this way" ...

I will grind on this some more, but in the meantime,

%

    if [[ -n "${OUPUT_FILE}" ]]; then
        exec > "${OUPUT_FILE}"
    fi

%

Should give you the resulting formatting you were expecting, ie:

if [[ -n "${OUPUT_FILE}" ]]; then
    exec > "${OUPUT_FILE}"
fi

[TekWizely]

OK so I realize that you're use-case seems quite valid and that I likely introduced a bug in my last release. It should be acceptable to have an "indentation of 0" where our base indentation is even with '%' We should also encourage copious whitespace, ie the leading and trailing blank lines in your example.

I'll have a PR up soon to address this and hopefully you'll be available to give it a check against your current templates.

Thanks !

[flaix]

In case you are curious, this is the template I am using. It has some larger statement blocks in which I put together the general bash script. This could mostly also be one block, but I found no way to add comments to the script other than using % # comment. After that I just use single statement lines to steer the output. Here you do find statement lines with different indentation.

[TekWizely]

Just a quick chime in re: comments.

So this input file:

comments.tpl

%# Bash-TPL comment - will not leave template
% # Statement line comment
%
# Block statement comment 1
# Block statement comment 2
%

Should generate:

comments.sh

# Statement line comment
# Block statement comment 1
# Block statement comment 2

Are you seeing something different in your local?

[flaix]

I tried it again and the comments work as you said. I can't remember why I didn't get it to work before. Either something changed meanwhile, or I hit an edge-case somewhere, or I just was too dumb. =)