Re: Feature branches review please

[Ergus <spacibba@aol.com>]

On Thu, Nov 05, 2020 at 10:00:57PM +0000, Gregory Heytings via Emacs development discussions. wrote:
>
>>>This has been discussed at length earlier: it is in practice 
>>>impossible to calculate the height of the minibuffer, and to 
>>>calculate the size of the completion candidates list to insert in 
>>>the minibuffer.  Yet you need to do both to have a correct 
>>>solution with the approach of the branch.
>>
>>With the current display code on `master`, I don't think the 
>>behaviors you refer to can qualify as incorrect.
>>
>
>Which is why I said, in the two previous mails, "not 100% correct" and 
>"not always correct".  I did not think it was necessary to repeat 
>"always" here.
>
>>
>>You can argue that they are less often preferable than some other 
>>choice, but that's a far cry from incorrect, IMO, and then should be 
>>fairly uncommon.  So it's definitely not very high priority and 
>>shouldn't decide whether we install a particular version of the code 
>>right now.
>>
>
>My point is that now that `(setq icomplete-separator "\n")' works (in 
>most but not all cases), there is no need for the specific 
>vertical-icomplete implementation anymore.  What is (or could be) 
>needed is an implementation that is "more correct" (correct in all 
>cases).
>
I don't totally agree is the same than the branch.

The completion like "compi{compilation" with fido mode is still there,
in the same line and is not intuitive; the ellipsis is not shown and the
{} and [] are still there and hard coded. icomplete-prospects-height is
not respected either because the number of candidates is still
calculated with the window-width and adding the candidates length which
actually makes no sense at all in vertical mode.

The pixel calculation is just part of the modifications in the branch.