Re: About the 'minibuffer' frame parameter

[martin rudalics]

> #<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

That's not what I see in the image you posted earlier.  In the dump,
Window 9 is 76 pixels high (4 lines) while the minibuffer window is 19
pixels high (one line).  In the image, the window corresponding to
window 9 is only one line high as the minibuffer window.  Also, I doubt
that deleting the other windows via C-x 1 will automatically give Window
9 its modeline back.

> 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.

lv should give that window a different background so it can be
distinguished as such.  As a rule, if people use neither dividers nor
scrollbars/modelines, they should find some other way to distinguish
windows.  Otherwise, it's too easy to mix up their contents.

martin