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: Gregory Heytings
Subject: Re: A solution to display completion candidates after point in a minibuffer
Date: Sun, 04 Oct 2020 16:52:10 +0000
User-agent: Alpine 2.22 (NEB 394 2020-01-19)


No, that's not what I meant. In that case redisplay does not scroll and does not move point. Point simply becomes invisible.

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.


I did not say that there was a bug in redisplay here, I explained what happens, and you said there was a bug, that redisplay should never do this, and asked me to write a recipe, which I did.

Obviously, I do not do what I did above, to demonstrate what you said was a bug, in my code.



reply via email to

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