emacs-devel
[Top][All Lists]
Advanced

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

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


From: Eli Zaretskii
Subject: Re: A solution to display completion candidates after point in a minibuffer
Date: Sun, 04 Oct 2020 19:21:51 +0300

> Date: Sun, 04 Oct 2020 16:11:06 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> > No, redisplay will never accept a result that point is invisible.  If it 
> > ever does display such situations, it's a bug that needs to be fixed.
> 
> Never say never...
> 
> >> It becomes visible again after the next redisplay, a second or two 
> >> later.
> >
> > If such a situation exists, please describe how to reproduce it, because 
> > it's a bug we need to fix.  Emacs should never display a window where 
> > point is not fully visible.
> >
> 
> Here's a recipe:
> 
> emacs -Q
> (defun recipe ()
>    (interactive)
>    (set-frame-width nil 80)
>    (set-frame-height nil 30)
>    (switch-to-buffer (get-buffer-create "*Recipe*"))
>    (goto-char 1)
>    (let ((i 0)) (while (< i 60) (setq i (1+ i)) (insert (format "L%d\n" i))))
>    (goto-char 148)
>    (sit-for 0.25)
>    (add-hook 'window-scroll-functions (lambda (&rest args) (set-window-start 
> nil 1)))
>    (forward-line 13))
> M-x recipe
> press C-n

AFAIU, this is exactly why we say not to use window-scroll-functions
for this purpose.  IOW, there is indeed a bug here, and the bug is in
the Lisp code you presented: window-scroll-functions are not meant to
be used to affect redisplay, they are meant to inform Lisp programs
about what redisplay is about to do with a window.



reply via email to

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