On Mon, Apr 9, 2018 at 12:59 AM, Eric Sunshine <sunsh...@sunshineco.com> 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.

Reply via email to