On Mon, Apr 9, 2018 at 12:59 AM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote: > However, I'm concerned that this change may be going in the wrong > direction. A line in "### command list" section looks like this: > > command-name category [deprecated] [common] > > Although we don't currently have any commands marked with tag > "deprecated", we very well may have some day. More generally, new > optional or required tags may be added in the future. As such, the > line format is relatively free-form. Current clients don't even care > in what order the tags appears (following 'category') nor how many > tags there are. The new code added by this patch, however, is far less > flexible and accommodating since it assumes hard-coded columns for the > tags (and doesn't even take 'deprecated' into account). > > The point of the $match file was to be able to extract only lines > which mentioned one of the "common groups", and the point of the > 'substnum' transformation was to transform the group name into a group > number -- both of these operations were done without caring about the > exact column the "common group" tag occupied. > > Obviously, one option for addressing this concern would be to change > the definition to make the tag columns fixed and non-optional, which > would allow the simpler implementation used by this patch. Doing so > may require fixing other consumers of command-list.txt (though, I'm > pretty sure existing consumers wouldn't be bothered). I should follow up by saying that, although the current relatively free-form line definition is nice due to its flexibility, considering how infrequently command-list.txt is edited and how much more complex the script is to support that flexibility, changing to a definition in which tags are required and at fixed columns seems like the pragmatic thing to do.
