Re: completion, sorting of options

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Fri, Nov 10, 2023 at 6:04 AM Thomas Lauer <thomas.lauer@xxxxxxxxxx> wrote:
>
> From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
> Date: Thu, 9 Nov 2023 10:07:16 -0800
>
> > Combination of an unanticipated use case and the order in which
> > features like unsorted groups were added to "compadd" relative to the
> > implementation of _arguments.
>
> Weeeellllll, unanticipated use case... that's debatable IMO.

Unanticipated use of _arguments, not of sorting.  The anticipated case
was that not-sorting would only apply to completions that would not be
implemented by generic option-parsing in the first place.

> Obviously
> somebody thought that a no-sort option would be a good idea, in fact
> such a good idea that there are two ways to do it. But what they then
> proceeded to do was to have the nosort option sort just a tiny little
> bit anyway

Pretty much everything in completion is based on grouping related
results -- files can be grouped separately from directories, etc.
Thus sorting or not-sorting applies at the group level.  That
_arguments makes separate internal sets of options with and without
arguments has nothing to do with that, and everything to do with the
way "compadd" has to be called in each case so that in the second case
it can match up the arguments with their options.  It would otherwise
have to call compadd once for every option, rather than twice covering
the whole list of options.  It was not anticipated that anyone would
care.