On Fri, Jul 14, 2023 at 3:44 AM Martin D Kealey <mar...@kurahaupo.gen.nz> wrote:
>
> On the whole I think this is great, and thankyou for working up the patch,
> but I would like to offer some comments and suggestions:
Thanks for looking at it, feedback very much appreciated.
> One option that some other languages use is to find the terminator, and then
> use its indentation as the pattern to remove from the content lines. The
> problem of course is that it would take a double run over the content, but
> the benefit is that there'd only be one in-band signaling line instead of two.
I agree, this would be useful functionality, would be interested in
seeing your implementation.
> Secondly, the battle for 8-space tabs has been well and truly lost at this
> point, so hard-coding that constant feels like it's likely to be a source of
> errors.
>
> In order to be tab-agnostic, I can see two reasonable options:
> 1. remove only an exact match for the sequence of whitespace characters that
> occurs in the indicator line
I think a problem with this is that a coding style using mixed
tabs/spaces (such as the bash source..) would have
foo
EOF
saved as:
[tab]foo
[spc][spc][spc][spc][spc][spc]EOF
so I don't think it's feasible to record the indent level as a fixed
tab/space mix if we are to allow indentation deeper into the heredoc
using the document's native style, at least not without ending up back
at the problem of needing to pick a tab stop width to use.
Personally, I don't use this indentation style (but don't wish to
precipitate an argument everyone is surely tired of) so I don't have
much of an opinion on what would be useful here. One slight point in
favor of keeping the 8-space wide tab approach is that this is how
readline renders literal tabs as well.
