make block definitions more flexible and intuitive

[sebkopf]

there's several aspect so this feature request:

1. recognize that orbi_define_block_for_flow_injection is the more universal function and should just be renamed to orbi_define_block (with orbi_define_block_for_dual_inlet being the more specialized case) - with proper deprecation of course that the old orbi_define_block_for_flow_injection still exists but throws a warning once every 8 hours that it's now just orbi_define_block
2. rename sample_name to block_name in orbi_define_block since sample_name is too specific, this can be a reference material or a sample and sample_name is confusing in this context
3. allow for filename parameter to specify which file(s) to define a block for (this make sense for both orbi_define_block and orbi_define_blocks_for_dual_inlet) - default is NULL which means define the block for all files
4. introduce an orbi_define_blocks_from_table function that allows block definitions from a tibble or csv/tsv/xlsx file - careful to still allow dynamic assignment of sample_name from other variables (see orbi_define_block_for_flow_injection does not allow dynamic definition of sample_name #64)

@123caj and @FR86, what do you think of this implementation suggestion?

[FR86]

Sounds good, though I have some trouble wrapping my head about all the intended and possible use cases for blocks.

Starting from where I personally am now (running HPLC flow injections), I

• typically only have one block with good data
• could possibly see the need to exclude a section somewhere in the middle (haven't run into that yet, but imagine a temporary spray issue)
• Want to adjust start and/or end of the data block for individual files (e.g. when there's a blockage or spray issue after minute x)

Looking at the implementation an the needs of continuous flow injections (also possibly for more complex HPLC setups with online switching to reference or similar), there are different types of blocks. This leads to the question whether it makes sense to continue just numbering the blocks in the face of possibly disjunct data blocks. I could see that switching block from being a number column to a block type column would allow you to define multiple chunks of data and reference blocks. Is that what you intend with renaming sample_name to block_name? How do you keep block_name and the block integer in sync?

In the context of #64 (see my comment), I imagined it would be possible to apply block definitions to all samples that match specific criteria, be that a str_detect(sample_type, "standard") or something else. Maybe I run my standards for a longer or shorter time than my samples? Or I see some other shared feature of samples I want to adjust block definitions for? I don't know if this is still relevant, as with your new proposal, you intend allow using a table for block definitions.

I guess that leads to the question how defining a uniform block layout for most of the samples and then adjusting would work, continue to use orbi_adjust_block or allow for overwriting a general definition for specific cases in the table already? Possibly, there could also be helper functions that populate the table based on user-defined criteria?

I hope some of the above makes sense 😁