On Wed, Jun 2, 2021 at 12:46 AM Dmitry Gutov <dgutov@yandex.ru> wrote:
Indeed. Indeed that does show that we simplify the code and can keep
the current calling convention. But then why should we? Its akwardness
becomes even clearer there: calling the same function twice in quick
succession with different second arg for two different types of return value.
I think the awkwardness comes from the general organization of
minibuffer.el rather than from this particular addition.
Yes, yes. Just that this particular addition pulls things in the wrong
direction, in my opinion.
Another pain point in minibuffer is the representation of candidates.
Sometimes they are strings, sometimes they are lists of strings with
prefixes and suffixes, lots of silly "if consp". Really should all be slots
in a completion object.
Whether this results in better minibuffer.el code is debatable: your
diff has more additions than deletions, and one rather long line.
Oh sure, that function is slightly more complicated, but if you look at
completion--insert-strings
completion--insert-horizontal
completion--insert-vertical
completion--insert-one-column
display-completion-list
minibuffer-completion-help
You'll find they are all simplified.
Yeah, OK, that's a recent change I haven't read yet. But couldn't any of
these functions fetch the current group-fun based on the minibuffer
contents and the current global values?
Yes, but in that case, a dynamic variable is better than repeating
that little md dance.
It's a property (method) of a completion table, isn't it?
We're talking about different things. The group function is a property
of the completion table. Each invocation transforms a completion,
meaning it produces a property of a completion. An that property could
be stored in the completion, whatever the format.