Re: A solution to display completion candidates after point in a minibuffer

[Stefan Monnier]

>>>> Also this has some problematic aspects: - it focuses all its energy on
>>>> showing the text before point, which is often the right choice, but
>>>> not always.
>>> Indeed, that's not always the right choice, which is why this solution
>>> does this if, and only if, the buffer-local variable
>>> start-display-at-beginning-of-minibuffer has been set, in
>>> minibuffer-setup-hook.
>> But it depends on other factors than "displaying the minibuffer". It can
>> vary over the lifetime of the very same minibuffer.
> Here I admit I have no idea what you mean.

In your example recipe, the first line is hidden.  I agree that it's
probably a bad idea *when you enter the minibuffer*.  But this same
display is probably a better choice after the user read the prompt and
knows what's the current directory, at which point the list of remaining
completions is likely going to the main focus.

>>> This I cannot do, alas, I'm not an expert.  I tried this solution
>>> extensively, on different Emacs versions.  Perhaps there are cases where
>>> it does not work, but I doubt it.
>> I'd be uneasy using such code without some vague understanding about *why*
>> it works.
> The code of xdisp.c is rather intricate (to say the least), but if a vague
> understanding is enough, I can explain what I understood.
> After resize_mini_window(), redisplay_window() is called, and its
> force_start part is executed, where run_window_scroll_functions() is called,
> which updates startp and therefore w->start.  This gives the user the
> possibility (and as far as I can see it is the only possibility for the
> user, with Lisp functions) to update window-start between
> resize_mini_window() and redisplay.  So set-window-start works, while other
> operations (such as an explicit scroll-up or scroll-down) might not.

After `set-window-start`, the redisplay will be inevitably re-started,
which in turn might decide to scroll and thus
`run_window_scroll_functions`, etc...

IIRC the reason it won't scroll the second time around is because point
should be visible (and redisplay would only scroll in order to move
point within view).

>>>> I don't understand why the kind of face in use would make a difference
>>>> w.r.t needing to use `post-command-hook`.
>>>
>>> I don't understand it either, alas.  An example, which does not work
>>> without start-display-at-beginning-of-minibuffer in post-command-hook
>>> with Emacs 26.3 (but works without it with Emacs 27.1):
>>
>> Thanks for the example.  I think this highlights the need to better
>> understand how/why this works.
> In fact I think this example demonstrates a (minor) bug in Emacs, given that
> the exact same code gives a different behavior with different versions of
> Emacs.  I could only reproduce this bug with variable width faces, with
> which I guess that some rounding approximations happen here and there.

Maybe because from the redisplay's point of view, there is no
scrolling involved on the first redisplay of the minibuffer?


        Stefan