> ==============================================
> | 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
#<window 9> 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
#<window 7> parent: #<window 9>
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
#<window 6 on Quick_Start_for_RTL_Users_9June16.pdf> parent: #<window 7>
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
#<window 8 on Quick_Start_for_RTL_Users_9June16.org> parent: #<window 7>
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
#<window 10 on Quick_Start_for_RTL_Users_9June16.pdf> parent: #<window 9>
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
#<window 4 on *Minibuf-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 ;-)
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.