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: Sat, 03 Oct 2020 12:31:54 +0000
User-agent: Alpine 2.22 (NEB 394 2020-01-19)



I'd be uneasy using such code without some vague understanding about *why* it works.


I studied this in a bit more detail.

What happens in the normal case (with icomplete-mode, icomplete-separator set to "\n", and window-scroll-functions set to nil) is the following:

1. redisplay_internal() calls resize_mini_window() and redisplay_windows(),

2. redisplay_windows() calls redisplay_window_0(), which calls redisplay_window(), and the "recenter" part of redisplay_window() is executed.

This happens twice (for each window in the frame) before redisplay_internal() returns. It happens twice because FRAME_GARBAGED_P, because the windows have been resized, which means that the "goto retry" jump is executed. This means that run_window_scroll_functions() is called twice (which has of course no effect if window-scroll-functions is nil).

When window-scroll-functions is set to start-display-at-beginning-of-minibuffer, the same happens, except of course that start-display-at-beginning-of-minibuffer is executed twice. The first time the "recenter" part of redisplay_window() is executed, start-display-at-beginning-of-minibuffer sets w->force_start and w->start. Then resize_mini_window() sets w->start again, but redisplay_window() is called again, and this time it is its "force_start" part that is executed, which calls run_window_scroll_functions(), after which try_window() updates w->start to the window-start value set in window-scroll-functions.



reply via email to

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