sh
sh copied to clipboard
syntax: consider configurability of continuation indent size
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!
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.
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 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
?
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 :)
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 :)
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.
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 ...
We can reopen for sure, if only to keep tabs on https://github.com/editorconfig/editorconfig/issues/412.