RE: [External] : Re: [PATCH] `completing-read`: Add `group-function` support to completion metadata (REVISED PATCH)

[Drew Adams <drew.adams@oracle.com>]

> I do believe completion tables should not
> define _presentation_, only information (with
> some well-defined exceptions, maybe).

I agree with this (IIUC).  Strongly.

Sorting (for both listing and cycling) can be one
example of such presentation.

However, I'd put it this way:

In order to affect/realize presentation, one should,
in general, not _have_ to fiddle with the completion
table.

___

This doesn't mean that it should be impossible to
include in the table (or metadata or whatever) some
info that can be used in some ways for presentation.

The point is that presentation of candidates (both
before and after matching) can often be logically
separate from definition of the domain of candidates
to match against, filter, and choose from.

And in practice also, the two can often/usually be
separated.  That is, they can be kept separate if we
don't hard-wire the completion table as the place
where such presentation-support info needs to be
provided.

(I'm guessing this was also your point - what you
meant.  And you too mentioned exceptions.)

___

As a result of this point of view, we should try
NOT to think of supporting presentation concerns by
adding features to the completion table etc.  There
should be no dependence of presentation realization
on the table etc. - in general.

I mentioned sorting as being presentation: put
candidates in a particular order.  But some kinds
of sorting can be closely tied to a particular
completion style (for example): they might be
appropriate only for certain styles, or certain
styles might naturally lend themselves to certain
sort orders.

In addition, a completion "table" that's a function
can also combine some quasi-presentation within its
definition of the domain of candidates.  E.g., user
partial input (matching) can be part of the domain
definition.

Same thing for a "table" that's generated on the
fly by some process.

Presentation and the data to be presented can, IOW,
be mutually defined in some cases.

But the larger point is that it should be possible
(easy) in many cases to implement presentation
separately from definition of the table, metadata,
etc.

Again (aside from some exceptions) sorting is an
example: code and users should, in many cases, be
able to change sort orders during the same process
of completion (e.g. invocation of `completing-read').