Feature: Add option to not detect alignment

[eutwt]

An option to not detect alignment would be useful. I think disallowing alignment in code style guides is fairly prevalent. PEP 8 advises against it. The top stackoverflow result for the question has split answers, with the top-voted answer advocating strongly against it.

For me personally, the reasons I'd like the styler I use to not allow alignment in code are

• Alignment can't be done by styler, only ignored. So if someone aligns one call then it is in a different style than the rest of the code after styling, unless I've somehow convinced everyone on the project to manually align all their code. I'd prefer there to be no red-flag "oh I guess Bob wrote this" signs in the codebase post-styling.
• It requires reviewers of a pull request to review more than they need to. It messes up the commit history / merges / git blame

More on point two in case it isn't obvious what's meant:

Say I'm working on a project and need to add some arguments to this function call. The person who wrote it ran styler, and it was left as-is because it recognized the alignment.

call(
  x = 1,           p = 3,
  y = "something", z = 9
)

Ok, so now I add my arguments

call(
  x = 1,           p = 3,
  y = "something", z = 9,
  areallylongarg = 4, extra_arg = 44,
)

That doesn't look right, let me use styler...

call(
  x = 1, p = 3,
  y = "something", z = 9,
  areallylongarg = 4, extra_arg = 44,
)

After styling the selection line 2 is changed, even though it wasn't part of my code edit. If I submit a pull request, the reviewer will have to read line 2 to make sure I didn't break anything, rather than simply looking at the single line I added. (Ok two lines isn't much but you can imagine cases where there'd be more)

[lorenzwalthert]

Thanks for the detailed explanation. I'll think about this. One thing I can say is that I'd probably prefer to maintain backward compatibility in the output so the default will most likely remain detect alignment. Also, it would most likely be governed by a an argument to the styler (e.g. style_text()) vs. an R option or env variable, as other configurations that are not style specific are already handled there.

[lorenzwalthert]

@eutwt I finally implemented this. Can you have a look at #932 and tell me if naming etc. makes sense for you and renv::install("r-lib/styler#932") gives the desired result?

[eutwt]

Great news! I may not have the time to take a look at this until this weekend

[eutwt]

Thanks for working on this feature! Your test case (second example below) works, but the first example below does not work the same way and I can't tell why.

renv::install("r-lib/styler#932")
#> Installing styler [1.7.0.9000] ...
#>  OK [copied cache]
library(styler)
options(styler.ignore_alignment = TRUE)

style_text('
call(
  argone = 1,
  two    = 2
)
')
#> 
#> call(
#>   argone = 1,
#>   two    = 2
#> )

style_text("
call(
  xb = 13,
  t  = 'a'
)
")
#> 
#> call(
#>   xb = 13,
#>   t = "a"
#> )

^{Created on 2022-03-23 by the reprex package (v2.0.1)}

[lorenzwalthert]

I think it's because that code was cached, you should be able to see it if you change one character in your exapmle. So we need to add the option to the cache as a key.

[lorenzwalthert]

I think it's fixed in the PR now. Can you try again?

[eutwt]

It appears to be working correctly now, both for this example and in general, including through the Addin. Thanks again for the feature!

renv::install("r-lib/styler#932")
#> Installing styler [1.7.0.9001] ...
#>  OK [copied cache]
library(styler)
options(styler.ignore_alignment = TRUE)

style_text('
call(
  argone = 1,
  two    = 2
)
')
#> 
#> call(
#>   argone = 1,
#>   two = 2
#> )

style_text("
call(
  xb = 13,
  t  = 'a'
)
")
#> 
#> call(
#>   xb = 13,
#>   t = "a"
#> )

^{Created on 2022-03-24 by the reprex package (v2.0.1)}