emacs-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] (icomplete-vertical-mode): Add support for affixations and,


From: Daniel Mendler
Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for affixations and, annotations
Date: Sun, 23 May 2021 22:14:12 +0200

On 5/23/21 9:55 PM, João Távora wrote:
>>> Can you give a visual example of what it looks like for a given completion
>>> table, ...
>>
>> I attached two screenshots:
>>
>> - M-x
>> - `describe-symbol` if `completions-detailed` is set
> 
> Thanks, I wasn't aware of this new framework and think this looks very
> nice and is extremely useful.  I could get your second example to work,
> but not the first (the M-x one).  What am I missing?

Ah, I forgot to tell you that. The M-x annotations are guarded by
`suggest-key-bindings`.

>>> It seems that neither affixation or annotation were present in non-vertical
>>> icomplete.el before your patch.  Do you have an idea why?  Should they
>>> be added there, too?
>>
>> There is not enough space in the vertical display.
> 
> You mean in the horizontal one-line display right?  In the vertical
> display there is space, so we are enabling it there.

Yes, I meant that the horizontal display does not have enough space.

> After my sig, I attach a very slightly simplified (and untested) version
> of icomplete-affixate, using `cond` instead of nested `ifs`.  But the
> main thing I wanted to note at this point, is that I find this
> "affixation" design confusing and flawed.

I have not been involved in the initial design of this, the
`affixation-function` is there for quite a while already.

I would also be happy with an extension to the `annotation-function`,
where the returned annotation string is the suffix and can be
propertized with an additional string for the prefix.

> I also don't understand why :affixation-function is given a full list of
> completions, when it is presumably meant to return a list of exactly the
> same length.  Seems like a potential hazard to allow this function to do
> filtering.

It is not allowed by the definition of the function.

> So, unless I am missing something (known to happen), this seems like a
> misdesign which would be nice to correct before the Emacs 28 release
> and/or too many external packages start relying on this.

For what is worth, my packages already rely on this. But I would have
this changed quickly given a modified definition of the
`annotation-function`. I am not aware of other packages already using
this functionality (I searched around for this at some point).

Daniel



reply via email to

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