Open Aspecky opened 2 years ago
I do the same thing, this would be much appreciated.
Interesting, personally I find the difference in indent helps, but I can definitely see where you are coming from.
I wonder if we should just leave a newline at the end of an if block if one was present originally. It might be reasonable rather than a whole option for it. Also, do you only keep this newline for blocks above another block? (i.e., you don't have a newline between the last block and end
)
Oh right, I forgot to mention that, if there was an empty line in the last end
, it should be removed, because it doesn't serve any purpose.
So this:
if true then
local var = 2
var += 1
var += 1
var += 1
elseif true and not true then
local var = 3
var += 1
var += 1
var += 1
end
Would become this:
if true then
local var = 2
var += 1
var += 1
var += 1
elseif true and not true then
local var = 3
var += 1
var += 1
var += 1
end
Personally, I do not like the idea of this happening. I would want StyLua to reformat this and remove this blank line in code I format with it. Part of why I use StyLua is to remove formatting decisions like this and so my code is formatted the same each time.
Personally, I do not like the idea of this happening. I would want StyLua to reformat this and remove this blank line in code I format with it. Part of why I use StyLua is to remove formatting decisions like this and so my code is formatted the same each time.
Which is why this could be a toggleable option in the settings, that will satisfy both parties.
Which is why this could be a toggleable option in the settings, that will satisfy both parties.
Yeah, this would be better. I was mostly referring to this:
I wonder if we should just leave a newline at the end of an if block if one was present originally.
I wonder if we should just leave a newline at the end of an if block if one was present originally.
No, that would ruin the reproducibility. Personally this is an option I won't use. I don't care if the feature gets added, but having it decide whether or not to do something based on the input formatting ruins the predictability of what would come out. Putting it behind an configuration option would allow it it exist as a feature without messing up those of us that would prefer actual normalization.
+1 there. I no longer agree with the idea of relying on input to determine output. The most major problem being that in a project it now depends on how the user originally formatted the code (and then style nits all come back again! "Please delete this newline").
This feature, if added, would be added behind an option and would apply in all cases
Any news on this? Just my 2 cents, but I don't think an option is needed, since stylua already respects single empty lines most of the times, even inside tables. Can't the rule be simply to preserve empty lines where they are, trimming multiple empty lines into one at most? If option should be, maybe allow the user to specify how many empty lines to preserve:
preserve_empty_lines = 2
And in that case, never remove empty lines anywhere, up to that value of consecutive empty lines.
But imho empty lines aren't a formatting issue, it's easy to delete them yourself, but if you actually want them and the formatter keeps deleting them, that's an issue.
Lot of times I have these inevitable if-else ladders and it gets a bit hard finding my way through them which is why I leave an blank line before my next
elseif
so it becomes easier to read, like this:But the formatter removes that blank line and kills readability for me, so it becomes like this:
And it gets much worse the longer the code is and the longer the ladder is. I think there should be an option to leave blank lines there for people like me.