Generating multiple HRG-entries from a single MRG-entry

[RieksJ]

It happens that a particular term (e.g., "Human Readable Glossary Tool") has an abbreviation or mnemonic (e.g., "HRGT") that curators may want to include in a HRG, by creating a HRG-entry for the abbreviation, with a text saying something like "See ", e.g., "HRGT: See Human Readable Glossary Tool".

One way to do this is to allow the HRGT, like the TRRT, to use multiple converters, where the behaviour of the HRGT then would be that it would invoke all specified converters for every MRG entry that it treats. Since a HRGT-converter either makes a HRG-entry (or produces an empty string), that the HRGT simply sorts in the end and then concatenates to form the HRG, this would provide users with lots of (additional) flexibility.

This issue calls for implementing the feature of the HRGT using multiple converters, as described above.

[Ca5e]

How do we handle the situation where we have multiple converters specified on the command line, or configuration file, and also find a converter specified within the MRGRef? I believe making the MRGRef interpreter regex able to also detect converter[n] options will require some strange workarounds with named capturing groups. The most straightforward solution would be to ignore all of the other defined converters for the specific glossary and strictly use the one as specified in the MRGRef if it exists. I suppose this limits the use of the MRGRef converter option slightly. It is probably still possible to achieve the requested functionality within a single converter by using a each helper.

[RieksJ]

Here's my understanding:

• tools may have their own defaults for csaes where there is no config file or commandline param
• anything in the configuration file is there to provide defaults for tools within a particular scope.
• the commandline is used
  • for testing out stuff locally
  • possibly also as part of a github/gitlab workflow So the commandline has top prio, then the config file, then the defaults of the tool.

The MRGref is special, because it adds a new way of specifying stuff as part of a named capturing group of an importer. I do not see a reason why this might (in future) not be generalized further, e.g., that a term-ref interpreter might somehow include a specification of how it should be converted. The fact that this makes the term-ref text messy (similar to the MRGref) would then be something that authors should live with - pay the 'cost' of this messyness to obtain the benefit of such flexibility. Let me be clear: we're not going to do that now, it's just for getting our thougts in order.

It seems to me that if authors take the trouble of specifying messy MRGrefs/TermRefs, that should take precedence over anything else.

Once a tool has decided what the sourcer of a particular (array of) arguments is, it should stick to that. In other words, if the commandline specifies a single converter and the config file specifies multiple ones, then the source is the commandline, and con[2] that is specified in the config file does not get used.

I would say that con[error] is NOT one of the elements of the con array for this matter, but is/should be an argument/parameter in its own right, so that - using the example of the previous paragraph - if the commandline doesn't specify a con[error] while the config file does, then the con[error] as specified in the config file is used where necessary.

I've drafted some text for this here. Pls check/review

@Ca5e does this help?

[RieksJ]

Like the (first) converter, a second (third, ...) converter for the HRGT will be executed for every MRGEntry that the HRGT processes. This means that we can generate multiple HRG-entries from a single MRGEntry, which is beneificial, e.g., if an MRG entry also specifies abbreviations, which can then get their own HRG-entry.

[Ca5e]

For the HRGT, do we want the n in converter[n] mean the count from which to start using a specific converter, or the order in which to use converters? For example, depending on the approach we choose:

converter[1]: {{glossaryText}}
converter[4]: {{glossaryTerm}}

will result in:

This is the glossaryText value of the term Test.
Test

or

This is the glossaryText value of the term Test.
Test
Test
Test

[RieksJ]

• [x] To be documented for TRRT: If, in the array of converters, an index is 'missing' (e.g., indices are 1, 2, 6), this means that for the first entry c1 is used, for the 2n, 3rd, 4th, and 5th entry c2 is used, and for all susbsequent entries c6 is used.
• [x] For the HRGT, the indices should just be different, as every one of them will be executed for a given MRG-entry.
• [x] For the HRGT, the error-converter will be called when the MRG that is identified in the MRG-entry doesn't exist/isn't found.

[RieksJ]

Done.