Feedback on table formatting

Thank you for your continued work on many R tools, including air. I understand that you are open to feedback on the experimental table formatting, so I wanted to provide some comments.

For reference, here is the current table formatting from air, reproduced from the docs.

tribble(
  ~customer   , ~product   , ~price  , ~units_sold ,
  "ACME"      , "Computer" , 1499.99 ,          25 ,
  "Globex"    , "Monitor"  ,  889.5  ,        1005 ,
  "Stark"     , "Tablet"   ,   99.99 ,         304 ,
  "WayneEnt." , "Tablet"   ,  259    ,          40 ,
)

Below are my reactions and opinions to the experimental feature, which I hope will be helpful, even if disregarded.

Visually looks wrong and rules are unintuitive

My initial response and opinion is that this looks quite wrong. In fact, when I first saw it, I thought something in air was broken or that there was a weird conflict was happening with my Positron settings. The two main concerns that I see are (1) the rules are complex making it feel inconsistent and (2) there's an extra space introduced.

Complex rules

Obviously, this is my opinion, but hopefully one based on experience: the complex rules look unformatted. When writing data in this way, I do not expect this set of alignment choices. In my own code, where I only had years (right-aligned) and strings (left-aligned) intermixed, rather than sorted it looked very weird because it bunches around the ,s.

The core non-taste issue that I see is that depending on the content, it will refactor in as-if random ways, even if they are intended. Consider the case in which we add an explicit integer indicator to one of the entries. It produces:

tribble(
  ~customer   , ~product   , ~price  , ~units_sold ,
  "ACME"      , "Computer" , 1499.99 ,   25L       ,
  "Globex"    , "Monitor"  ,  889.5  , 1005        ,
  "Stark"     , "Tablet"   ,   99.99 ,  304        ,
  "WayneEnt." , "Tablet"   ,  259    ,   40        ,
)

or similarly, by being somewhat explicit as R would generally allow. This now converts to decimal-left aligned, even though the statements are equivalent. Why are some numeric statements right-aligned, but decimal numeric statements are left-aligned?

tribble(
  ~customer   , ~product   , ~price  , ~units_sold ,
  "ACME"      , "Computer" , 1499.99 ,   25        ,
  "Globex"    , "Monitor"  ,  889.5  , 1005.0      ,
  "Stark"     , "Tablet"   ,   99.99 ,  304        ,
  "WayneEnt." , "Tablet"   ,  259    ,   40        ,
)

These rules result in additional churn that looks like there's something wrong, rather than an intentional design. Yes, the integer will be converted, but this is how we might write the data if we are inputting mixed outputs, such as those from count models and linear models.

Extra space

Even though some pieces are advertised as being right-aligned, there is always an extra space inserted. This isn't documented anywhere that I could find. I would expect it to look more like:

tribble(
  ~customer  , ~product  , ~price , ~units_sold,
  "ACME"     , "Computer", 1499.99,          25,
  "Globex"   , "Monitor" ,  889.5 ,        1005,
  "Stark"    , "Tablet"  ,   99.99,         304,
  "WayneEnt.", "Tablet"  ,  259   ,          40,
)

What I would have expected

I understand the general desire for a table-based format. Flattening everything to ~col1,\n~col2... makes it hard to edit, especially using Positron's format-on-save feature. In practice, I would expect something simple as a default styling. This avoids learning custom rules for specific functions.

Something like styler's format, which keeps correct line breaks but removes extra spaces:

tribble(
  ~customer, ~product, ~price, ~units_sold,
  "ACME", "Computer", 1499.99, 25,
  "Globex", "Monitor", 889.5, 1005,
  "Stark", "Tablet", 99.99, 304,
  "WayneEnt.", "Tablet", 259, 40,
)

Or, if leaning more into the table, something which logically and cleanly keeps columns in a consistent fashion. The below simply aligns the commas and the entries so you can see the columns in a predictable, logical way. This is robust to the decimal or 1L type edits.

tribble(
    ~customer,   ~product,  ~price, ~units_sold,
       "ACME", "Computer", 1499.99,          25,
     "Globex",  "Monitor",   889.5,        1005,
      "Stark",   "Tablet",   99.99,         304,
  "WayneEnt.",   "Tablet",     259,          40,
)

Either of these are simple and logically formatted, without introducing complex rules. I can understand the idea behind the experimental feature, but it seems both unusual and very opinionated for a default, opt-out behavior.

Perhaps one consideration would be to have a default table formatting which is purposely simple: retain lines and remove spaces, like styler does and allow this choice to be a per-repo opt-in to get complex behavior.

Start with the table-formatting section of the air documentation linked in the issue and reproduce the shown tribble examples. Compare the current behavior with the proposed simpler or consistently aligned alternatives. Done would require an agreed formatting direction and corresponding behavior, but the issue does not identify implementation files or tests.