emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: About the 'minibuffer' frame parameter


From: Kaushal Modi
Subject: Re: About the 'minibuffer' frame parameter
Date: Mon, 22 Aug 2016 16:27:45 +0000

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]