[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] `completing-read`: Add `group-function` support to completio

From: Daniel Mendler
Subject: Re: [PATCH] `completing-read`: Add `group-function` support to completion metadata (REVISED PATCH VERSION 2)
Date: Sat, 8 May 2021 08:24:05 +0200

On 5/7/21 7:55 PM, Daniel Mendler wrote:
> On 5/7/21 7:03 PM, Juri Linkov wrote:
>> I tried to remove `read-char-by-name-group`, but it has a feature
>> currently not supported by `group-function`:
>>   (defcustom read-char-by-name-group nil
>>     "How to group characters for `read-char-by-name' completion.
>>   When t, split characters to sections of Unicode blocks
>>   sorted alphabetically."
>>   =====================
>> It seems a new function is needed to sort groups, e.g. `group-sort-function`.
>> Maybe better to push your current patches, so it would be easier
>> to base the next patches on master?
> My original thoughts for a `group-function` proposal were such that the
> `group-function` had the capability to sort the groups. During the
> previous discussion with Stefan and Dmitry we somehow agreed that it is
> better to keep things simple and to not allow the `group-function` to
> sort the groups. Instead, sorting should only be provided by the
> `cycle/display-sort-functions`.

I should add to my last mail: Dmitry also proposed adding an additional
`group-sort-function`, which allows sorting the groups, on top of the
`group-function` as provided by my patches (See comment
https://github.com/minad/consult/issues/283#issuecomment-825891569). I
had hoped that the complication of such a function can be avoided. But
if you want to have it in any case I think it is better to reconsider
the whole design and in particular look at my original implementation of
the group function (point 4 below).

In my patches we have a single `group-function : string -> bool ->
string`, where the second argument determines if the group title should
be returned (nil) or the candidate should be transformed (non-nil). If
we add the `group-sort-function` we have this:

1. Current patch + group-sort-function
   1.1 group-function: string -> bool -> string (title/transform)
   1.2 group-sort-function: list string -> list string

This does not look particularly coherent to me. I would not use a single
function for transformation/title and another function only for sorting.
There are the following alternatives to consider, if one takes a step back:

2. Use separate functions
   2.1 group-title-function : string -> string
   2.2 group-transform-function : string -> string
   2.3 group-sort-function : list string -> list string

For 2.3, Dmitry proposed a more complicated sorting function which
allows weighting the candidates. I am not in favor of that, I prefer a
simpler design, see

3. Use a single function with an action argument
   3.1 group-function : (action=title) -> string -> string
   3.2 group-function : (action=transform) -> string -> string
   3.3 group-function : (action=sort) -> list string -> list string

With this single action argument a minimal group-function implementation
can still pass through the second argument when action/=title.

4. Use a single function with a type-based operation
   4.1 group-function : string -> string (return transformed candidate)
   4.2 group-function : list string -> list (list string) (return
grouped candidates, group function determines the order of the groups)

This was my original implementation, see


reply via email to

[Prev in Thread] Current Thread [Next in Thread]