Put differently, if people say "no! we want custom rules!", then I will happily defend the fact that jarl is a better tool without that 😆

I think ruff proved that a linter doesn't have to provide a way for users to add custom rules to be successful. Instead, letting jarl just implement lots of useful rules and categorizing them into families does seem like a much better approach.

Not currently, but I've opened github.com/quarto-dev/q... for us to consider

yes, yes it would 🙂

It's pretty amazing how the `|` and extra `()` really add to the cognitive load vs a simple `,`

That's purposeful in the name! If you see "when" in one of our function names, then I'd like it to mean that you should see some logical vectors being used in some way.

Strong agree!

I believe it's possible you've misinterpreted the examples. Both `filter()` and `filter_out()` combine conditions using `&`. Have you read the tidyup? github.com/tidyverse/ti...

They are different. when_any/all when you have arbitrary logical conditions. if_any/all when you have a single function you want to apply to multiple columns.

extremely, they are backed by these github.com/r-lib/vctrs/...

Let me introduce you to `replace_when()` in tidyup #7 🙂 github.com/tidyverse/ti...

Yes! They are "just" normal vector functions so they can be used anywhere, even outside a dplyr verb. If you are familiar with `pmin()` and `pmax()`, these are really the idea of `pany()` and `pall()`, but with friendly names. See this for a use in `summarise()` github.com/tidyverse/ti...

`when_any()` allows you to write `filter()`s that combine conditions with `|` rather than with `&`. This is so nice because your conditions stay comma separated, rather than having to squish them into one giant condition that uses `|` and adds extra layers of parentheses.

`filter_out()` is not just syntactic sugar!

If you've used `filter()` to drop rows, you've likely had to sprinkle in `& !is.na(col)` all over the place. No more! `filter_out()`'s default behavior should line up much better with your expectations around `NA`s when dropping rows.

I think that is exactly what ignoring trailing commas gets you. Say you delete condition 3 from this

filter(
TRUE,
vs==1,
mpg>20,
)

filter(
TRUE,
vs==1,
)

Note how you don't have to remove the trailing comma from `vs == 1,`, so the diff is contained to one line.

Can confirm that a formatter is "the hard part" and that Biome's infra works extremely well to build on top of, thanks again for all your work on making it generic enough to be reusable by others 🙂 github.com/posit-dev/air