On Mon, Aug 22, 2016 at 12:01 PM martin rudalics wrote: > > ============================================== > > | Win 1 - Buf x | > > ---------------------------------------------- > > | Mode-line for Win 1 | > > ============================================== > > | Win 2 - Buf x | > > ---------------------------------------------- > > | Minibuffer | > > ============================================== > > > > (I put to white box there to mask my work stuff. If I close that window, > > You mean "If I delete Win 1"? > Correct (C-x 0). > > the missing modeline for the bottom "Win 2 - Buf x" is created > > automatically. > > And what else do you see now in Win 2 besides the "- Searchd" string? > I see just one line and I can scroll that window up/down (but now I know exactly what's causing there.. copying Oleh to throw some light here too; more detail below). > > Note that the same "-Searchd" string is shown in the actual > > window on the top right and the bottom window auto-created exactly above > > the minibuffer (so I thought earlier that the minibuffer had 2 rows; it > was > > in fact an inactive window and thus that inactive window cursor face). > > In any case please do (window--dump-frame) for that frame - the result > of that dump is in a buffer called *window-frame-dump* and post the > result here. frame pixel: 1910 x 1096 cols/lines: 212 x 57 units: 9 x 19 frame text pixel: 1894 x 1096 cols/lines: 210 x 57 tool: 0 scroll: 0/0 fringe: 16 border: 0 right: 0 bottom: 0 # parent: nil pixel left: 0 top: 0 size: 1910 x 1077 new: 906 char left: 0 top: 0 size: 212 x 56 new: 48 normal: 1.0 x 1.0 new: nil # parent: # pixel left: 0 top: 0 size: 1910 x 1001 new: 830 char left: 0 top: 0 size: 212 x 52 new: 44 normal: 1.0 x 0.9294336118848654 new: nil # parent: # pixel left: 0 top: 0 size: 956 x 1001 new: 830 char left: 0 top: 0 size: 106 x 52 new: 44 normal: 0.5 x 1.0 new: nil body pixel: 940 x 981 char: 104 x 51 width left fringe: 8 left margin: 0 right margin: 0 width right fringe: 8 scroll-bar: 0 divider: 0 height header-line: 0 mode-line: 20 divider: 0 # parent: # pixel left: 956 top: 0 size: 954 x 1001 new: 830 char left: 106 top: 0 size: 106 x 52 new: 44 normal: 0.5 x 1.0 new: nil body pixel: 938 x 981 char: 104 x 51 width left fringe: 8 left margin: 0 right margin: 0 width right fringe: 8 scroll-bar: 0 divider: 0 height header-line: 0 mode-line: 20 divider: 0 # parent: # pixel left: 0 top: 1001 size: 1910 x 76 new: 76 char left: 0 top: 52 size: 212 x 4 new: 4 normal: 1.0 x 0.07056638811513463 new: nil body pixel: 1894 x 56 char: 210 x 2 width left fringe: 8 left margin: 0 right margin: 0 width right fringe: 8 scroll-bar: 0 divider: 0 height header-line: 0 mode-line: 20 divider: 0 # parent: nil pixel left: 0 top: 1077 size: 1910 x 19 new: 190 char left: 0 top: 56 size: 212 x 1 new: 10 normal: 1.0 x 1.0 new: 0 body pixel: 1894 x 19 char: 210 x 1 width left fringe: 8 left margin: 0 right margin: 0 width right fringe: 8 scroll-bar: 0 divider: 0 height header-line: 0 mode-line: 0 divider: 0 > I think that the appearance of that one line window is > more or less intentional but I have no idea who's responsible for it. > At least that someone seems to do very tricky things to your window > layout ;-) > I strongly believe it's this: http://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/packages/hydra/lv.el The mode-line-less window is exactly what lv.el does for creating hydras. What seems to happen is that the pdf-tools timer error does not allow a hydra to finish doing its job. ===== Error running timer ‘pdf-cache--prefetch-start’: (error "epdfinfo: No such page 0") ===== .. and I had bound toggling debug-on-error to a hydra head (hydra package jargon). I was able to recreate the same issue when calling any hydra. > > Please ignore that.. that bug is there but has nothing to do with your > > recent commit. > > I see it on emacs 25.1 RC2 too when I end up causing a timer error in > > pdf-tools package: > > I'd still want to see the output of ‘window--dump-frame’ for this frame > (no fear - it doesn't reveal any buffer contents). > Thanks for the retained interest in fixing this :) There are 2 things here: - I need to figure out why the pdf-tools timer issue is caused. Once that is fixed, with window issue should not happen as the hydras I launch will be allowed to do all the needed window layout cleanup. - Hopefully Oleh gets a chance to investigate the hydra/lv behavior under the timer error circumstances. -- Kaushal Modi