On Tue, Aug 25, 2015 at 7:25 AM, martin rudalics wrote: >>> Naively spoken it's obvious that when you shrink the minibuffer you show >>> more lines in the window above and ‘linum-mode’ has to add numbers for >>> those lines. And when you enlarge the minibuffer, ‘follow-mode’ will >>> lose some lines at the bottom of the left window and has to show them at >>> the top of the right window. >> >> In well-behaved modes this happens automatically, as part of >> redisplay. > > Via ‘pre-redisplay-function’? Well, we have `pre-redisplay-functions', with an s, defined in simple.el, and I've attached some (trivial) code that takes things a little further and calls a normal hook when a window's size changed. > How does a well-behaved mode detect > whether it has to make "this happen automatically"? By walking all > windows and checking whether their sizes, start and end positions > changed, I suppose. That's what my code does. I thought I could get away with using the arguments passed to pre-redisplay-function to limit which windows to check, but that doesn't work when we "goto retry" and re-run pre-redisplay-function. I will study the code in xdisp.c further and see whether I can understand what the purpose of must_finish is. >> I'd say, don't set the "size changed" flag unless the size really >> changed. > > Sure. Patch attached (no news on the paperwork so far). I'm not sure precisely which properties should be checked for change, though. I do think it would be best not to use set-window-configuration in restoring state after exiting the minibuffer at all. > Alternatively, Fset_window_configuration could run a modified version of > ‘compare-window-configurations’ to compare the current configuration > with the one to be restored and restore the old configuration iff these > differ. I'm not sure whether this would be any cheaper, especially when > the configuration does change frequently. I think it would be better to do this explicitly, even if we have to compare all properties. Thanks again to both of you, Pip