sh icon indicating copy to clipboard operation
sh copied to clipboard

syntax: consider configurability of continuation indent size

Open dmitry-kabanov opened this issue 6 years ago • 8 comments

Is it possible to tell shfmt to keep indentation as is when the indent is not standard (i.e., not 2, 4 spaces) when breaking lines with line-continuation symbol \.

For example, in the code like this:

echo "My very long string that I split over " \
     "several lines with manual indenation"

or this:

bin/my_prog arg1 \
            arg2 \
            arg3

Thanks for the wonderful tool!

dmitry-kabanov avatar Jan 04 '19 18:01 dmitry-kabanov

In the tool's default behavior, this is likely not a good idea - indentation should follow a single simple rule. However, we could perhaps add this to -kp, which lets users keep some custom spacings. Currently it doesn't allow custom indentation, as that defeats the purpose of a formatter. However, this seems like a fairly restricted use case, so I think it can be supported as long as tabs and spaces are not mixed.

mvdan avatar Jan 04 '19 21:01 mvdan

Noone else seems to agree that this is a useful feature, and I myself have no interest in it, so I'm going to close this for now. If someone wants to work on it as part of the -kp flag in the future, I'm happy to review a patch.

mvdan avatar Oct 13 '19 22:10 mvdan

@mvdan I came across this as our project uses double indentation on continuation, e.g.:

we indent:

if this; then
  # normal 2-space indent here
fi
command \
    --arg1 \
    --arg2 \
    --arg3
# ^ double indent (4 space) on continuations

would you accept a flag that either:

  • allows specifying a custom double indentation spacing, e.g. something like: -i 2 -di 4
  • flips indentation to use to double indentation, e.g.: -i 2 -di

?

joscha avatar Jul 21 '21 01:07 joscha

This thread is old, so as an FYI, I plan to remove -kp in v4: https://github.com/mvdan/sh/issues/658

It's true that "custom indentation" or "custom padding" are a recurring topic in the issue tracker, though. For example, see https://github.com/mvdan/sh/issues/498. Unfortunately, it's hard to please everyone without either disabling large parts of shfmt (-kp attempted to do this and it was a mistake for many reasons), or without adding lots more options, which expontentially add more complexity to the tool.

So for that reason, my default answer to more formatting options is a negative. Unless the option would be popular enough that it really can't be avoided. It doesn't seem to be the case here - or is there some very common/standard Shell style/formatting spec that defines this?

All in all, if you want to use shfmt, you have to accept you might need to tweak your formatting requirements a bit. shfmt has some options, but not an unlimited amount of them :)

mvdan avatar Jul 21 '21 16:07 mvdan

Hi @mvdan,

Thanks for your answer. ACK to -kp removal. The double continuation indent is a language-agnostic setup in our org. I briefly looked and couldn't find any shell-specific rules for bigger projects that make this a requirement. Having said that, continuation indent is a recurring theme in languages outside shell (https://github.com/editorconfig/editorconfig/issues/412) and some Editors (IntelliJ, which we happen to use mostly, vim) are supporting this out of the box. I've only recently discovered this project so i am not aware of the pain you have/had with -kp, so apologies for the missing context. Changing the continuation indent preference of our org because of my hopeful adoption of a shell formatter might not be as easy and as my hope is to format our shell files I thought I'd ask :)

joscha avatar Jul 21 '21 21:07 joscha

What you say sounds reasonable. There's always a tradeoff with consistency :)

If https://github.com/editorconfig/editorconfig/issues/412 becomes standard across languages, then I'd consider that a signal that we should attempt to support it, too - given that we support EditorConfig. If or when that happens, I'd be happy to talk about it. I'm now following the issue too.

mvdan avatar Jul 29 '21 10:07 mvdan

With https://github.com/editorconfig/editorconfig/issues/412 and #498 I think the original request outlined here makes more sense again. The -kp was a kludge to help with this; but never really worked.

Does it make sense to keep re-open the issue to keep better track of it?

For me personally; I sadly have watched for more then 2 years and have not been able to use shfmt for this reason :( So I'm eagerly looking forward for something that does what the OP in essence asks :) And as you rightfully pointed out too; I think it has been a request in the last few years in various forms too ...

oliv3r avatar Oct 13 '21 18:10 oliv3r

We can reopen for sure, if only to keep tabs on https://github.com/editorconfig/editorconfig/issues/412.

mvdan avatar Oct 13 '21 19:10 mvdan