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

[Gregory Heytings]

> > > [ FWIW, I just tried it in my local Emacs where I replaced the ad-hoc 
> > > `resize_mini_window` scrolling with the use of 
> > > `scroll-conservatively`, and I get the behavior that you seem to 
> > > prefer. ]
> >
> > Yes, that's not surprising, what your code does is essentially (or very 
> > close to) what I suggested to do in bug#43519 and bug#43572,
>
> Not really, because with my code, the window start is not explicitly set 
> to BOB unless the buffer's content is small enough to be completely 
> visible (the first version of my patch did, but not the current one).

That's correct indeed, but setting window start explicitly in 
resize_mini_window() is only a hint for redisplay, that can ignore this 
setting in particular when when point would become invisible.  So in 
effect it's (very close to) what I suggested to do.

> > Thank you, now I see what you mean.  IMO (and I would be extremely 
> > surprised if I were the only one with that opinion) seeing the current 
> > directory disappearing is disturbing (and from a newcomer point of 
> > view: very disturbing), so the prompt an user input should always be 
> > displayed (unless the miniwindow is too small of course).
>
> I agree it's suboptimal when entering the minibuffer.  OTOH it's a 
> perfectly acceptable behavior while editing the minibuffer's content and 
> can even be preferable in some cases to what you propose.

I don't think so, IMO the minibuffer prompt should be visible at all 
times.  A rough equivalent of what you propose in a GUI would be, for 
example, for the Windows File Explorer or the macOS Finder to suddenly 
become fullscreen when the directory entered contains more files than it 
can display with its current size.  But I will not argue further.

Anyway, what you think could be a preferable behavior (showing the first 
line(s) when entering the minibuffer, and hiding it/them when the user has 
already entered some data) is easy to do with the minibuffer-local 
variable solution I propose.  It suffices to (setq 
start-display-at-beginning-of-minibuffer nil) at some point.  It could 
become a user preference, something like icomplete-always-display-prompt 
with a default value t.

> > > 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 know, but I'm not sure about that.  If you (set-window-start 
> > nil 1) unconditionally in window-scroll-functions, this setting will be 
> > obeyed by redisplay, even if point is not visible anymore.
>
> Oh, indeed, in that case it would move point instead.

No, that's not what I meant.  In that case redisplay does not scroll and 
does not move point.  Point simply becomes invisible.  It becomes visible 
again after the next redisplay, a second or two later.