Enhancing HeaderOptions.R(n) Behavior

[Kvintochka]

The current implementation of HeaderOptions.R(n) consolidates the first n+1 lines of a CSV into a single-line header, joining fragments with spaces. For example, Name,Age\nFirst,Years becomes List("Name First", "Age Years").

While this provides a merged header, it introduces several challenges:

• Accessing Fields: Using generated NamedTuple for field access becomes cumbersome due to spaces and special characters in header names (e.g., `row.'Name First``). This hinders IDE autocompletion and feels unidiomatic in Scala.
• Multi-Row Header Preservation: There's a need to explore options for preserving the original multi-row header structure, rather than collapsing it into a single line. This would be beneficial for maintaining the original context and potentially for future printing.
• Normalization: Should we consider normalizing column names (e.g., converting Name First to Name_First) to improve usability and programmatic access?

[Quafadas]

Accessing Fields: Using generated NamedTuple for field access becomes cumbersome due to spaces and special characters in header names (e.g., `row.'Name First``). This hinders IDE autocompletion and feels unidiomatic in Scala.

Normalization: Should we consider normalizing column names (e.g., converting Name First to Name_First) to improve usability and programmatic access?

My instinct, is that these two are related, and probably, rather complex. If there was some sort of spec, that set out how CSV headers should be dealt with and / or these issues interact, then there would seem to be an obvious direction of travel. I'm not aware of such a thing. Possibly, Pandas does something sensible and we could attempt to mimic it. But...

Multi-Row Header Preservation: There's a need to explore options for preserving the original multi-row header structure, rather than collapsing it into a single line. This would be beneficial for maintaining the original context and potentially for future printing.

Again, I would agree that this is useful... But...

I agree that these things are potential problems. However, I think they are future problems. I'm not sure that they deserve investigating further at the moment for these reasons;

• The solution could end up being judgemental, possibly idiosyncratic to this project and not based on a true need
• My personal opinion, is that given project status right now the "killer feature" that would make it attractive for adoption, is the automatic inferral of types.

Hence, my current proposal is to acknowledge these as problems, and move on.

Question: In the context of this PR, #63 was the effort there wasted?

I would reject the idea, that the effort there was wasted. Although we know we are (deliberately) leaving problems open, once merged, that PR will leave a good way, to configure and extent the treatment of headers in future, as we (hopefully) hit real world usecases. That is already a big improvement, on thhe previous status.