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

[Stefan Monnier]

I think you should better define the problem you're trying to solve.

AFAIK the main issue ("when there are too many completion candidates,
the minibuffer prompt is hidden") has been solved by Eli, so without
some concrete cases where the result is still unsatisfactory it's
difficult to know what "better" means.  The code can't guess what should
happen in all cases currently because the information for that is simply
not available, so it remains a balancing act based on heuristics.

[ I sightly tweaked your code ]
> (defvar-local start-display-at-beginning-of-minibuffer nil)
> (defun start-display-at-beginning-of-minibuffer (&rest args)
>   (when (and start-display-at-beginning-of-minibuffer (minibufferp))
>     (set-window-start-at-begin (point-min) (point))))
> (defun set-window-start-at-begin (beg end)
>   (set-window-start nil beg)
>   (unless (pos-visible-in-window-p end nil t)
>     (set-window-start-at-begin (+ beg (/ (- end beg) 2)) end)))
> (add-hook 'window-scroll-functions #'start-display-at-beginning-of-minibuffer)
> (add-hook 'post-command-hook #'start-display-at-beginning-of-minibuffer)

This might indeed give a reasonable behavior in practice, but I'm not
sure it's better than what we have now.
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.
- There's of course a risk of inf-loop if (set-window-start nil (1- end))
  leads to (pos-visible-in-window-p end nil t) returning nil.  How/when
  could this happen, I'm not completely sure, but it doesn't seem impossible.
- `window-scroll-functions` says explicitly:

      Warning: Do not use this feature to alter the way the window is
      scrolled.  It is not designed for that, and such use probably
      won’t work.

  Now, I know experience shows that it does work at least in some cases,
  but if so I think the code should come with a clear comment explaining
  why that warning doesn't apply here (and maybe the corresponding
  C code should also get a comment explaining the
  properties/invariants/berhaviors that it preserves and that make such
  uses work, so we don't break it by accident).

> 2. The only drawback of the above solution is that is is not possible to
>    display an ellipsis ("...") at the end of the completion candidates list,
>    to indicate that some completion candidates are not displayed.  It seems
>    to me that this is a minor limitation.

Actually, it seems like your code would allow to do that by running some
icomplete code at the end of your `set-window-start-at-begin` to
truncate the overlay's text according to where the text is truncated.

> 7. (add-hook 'post-command-hook 'start-display-at-beginning-of-minibuffer)
>    is necessary only with variable width faces, but it is does not harm to
>    use it with fixed width faces.

I don't understand why the kind of face in use would make a difference
w.r.t needing to use `post-command-hook`.


        Stefan