Re: About the 'minibuffer' frame parameter

[Kaushal Modi <kaushal.modi@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5198 bytes --]

On Mon, Aug 22, 2016 at 12:01 PM martin rudalics <rudalics@gmx.at> 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

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

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

[-- Attachment #2: Type: text/html, Size: 7227 bytes --]