Sorting a HRG that contains entries created by different converters

[RieksJ]

I have come to appreciate the feature of having multiple converters create HRG entries, e.g.,

• have a 'regular' HRG entry created for every MRG entry, and
• if an MRG entry has an abbreviation specified (in its glossaryAbbr field), a HRG entry is created that states the abbreviation, and has as its description See: {glossaryTerm} (or so).

Before creating the HRG itself, the set of HRG entries are sorted according to the 'sorter' converter.
The problem is that if the sorter sorts on glossaryTerm, then the abbreviations are listed adjacent to their 'regular' entry, regardless of whether that is appropriate. The same issue exists if we sort on glossaryAbbr.

The problem is that each converters should be able to 'generate' its own sorting-value, so that the regular sorter can output glossaryTerm as its sorting value, and the abbreviation-converter can output glossaryAbbr.

How can we do this?

[RieksJ]

one way, perhaps, is that we make pairs (converter, sorter)[i], where the output of each converter is assigned the sorting value provided by the sorter in that pair.

We could do that by expanding the current syntax with multiple sorters.

Alternatively, we could do another parameter that takes two converters, such as -<newparam>[i] <converter>, <sorter>. I would consider this if we were to require mappings, so that we don't allow handlebars templates to be specified - see #46.

[Ca5e]

Pardon the late reply, I've had little spare time.
I suppose it's possible to start working with converter-sorter pairs. The size of the change doesn't seem that large considering the mappings of these items still have to be reworked.
Thinking about the issue, I believe it might also be solvable by sorting on the converter output of the hrg entries instead of using the sorter before processing the entries. For instance by making the default sorter sort on the output of each generated item instead of the {{term}}{{termType}} default.

[RieksJ]

Good to hear!
If you were to sort the converter output, I would think it is possible that various kinds of layout stuff around the text could be influential to the sorting and provide undesired outputs as well. Also, it would prohibit, e.g., sorting entries according to - say - the 'date of update' (that would typically not occur in the first part of the output).
Unless you can deal with such things, I would think we should stick to the ({converter}, {sorter}) pairs.