From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Kaushal Modi Newsgroups: gmane.emacs.devel Subject: Re: About the 'minibuffer' frame parameter Date: Mon, 22 Aug 2016 16:27:45 +0000 Message-ID: References: <579E3F9E.8020200@gmx.at> <83h9azl4s1.fsf@gnu.org> <57A4C0DE.3060506@gmx.at> <837fbvkofs.fsf@gnu.org> <57A5AF03.30807@gmx.at> <8360rck7kd.fsf@gnu.org> <57A84256.8030706@gmx.at> <83popji89w.fsf@gnu.org> <57A9940B.6030005@gmx.at> <8337mehu5u.fsf@gnu.org> <57A9FFDE.10106@gmx.at> <83pophhq1a.fsf@gnu.org> <57AA141C.5010701@gmx.at> <83mvklhluf.fsf@gnu.org> <57AB1AF1.2010205@gmx.at> <837fbohe5u.fsf@gnu.org> <57B97734.1090302@gmx.at> <57BB21D0.6070601@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11478678dd7eba053aab8744 X-Trace: blaine.gmane.org 1471883302 11116 195.159.176.226 (22 Aug 2016 16:28:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 22 Aug 2016 16:28:22 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics , Eli Zaretskii , Oleh Krehel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 22 18:28:17 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bbs5A-0002dq-Ib for ged-emacs-devel@m.gmane.org; Mon, 22 Aug 2016 18:28:16 +0200 Original-Received: from localhost ([::1]:42290 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bbs57-0002wi-Qr for ged-emacs-devel@m.gmane.org; Mon, 22 Aug 2016 12:28:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48086) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bbs4w-0002uS-MN for emacs-devel@gnu.org; Mon, 22 Aug 2016 12:28:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bbs4u-00056b-TG for emacs-devel@gnu.org; Mon, 22 Aug 2016 12:28:02 -0400 Original-Received: from mail-ua0-x230.google.com ([2607:f8b0:400c:c08::230]:33356) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bbs4r-000564-D2; Mon, 22 Aug 2016 12:27:57 -0400 Original-Received: by mail-ua0-x230.google.com with SMTP id 74so198433052uau.0; Mon, 22 Aug 2016 09:27:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mufMPLth0blwByXxFdG0bZks7rhn3z5Y71XDyxmhENg=; b=FlINnKPx+7fyaYvCzLm9RFO4J+RKNYN0ZM5zGJ1gwhcqSnkdBukJKIF6CXFMBGHtlM Wi8inU1Xu2M3WG0XM3GI8ohezwu8pjtG7u/IwfwXOTZFQlYMKpfcJApgZJCZTcFWvf8g TqpKnl8kkJB1bdehBf2acLrqZPfQsJJxkTYDzd67W/mTt1FKc0qiSPhLPG3xahckx3Jm aVjKzcODTs1js3f+UZLiB8MhfscB9jXqGaoRj4rHmLSQSURwzMZVrRgxrzhDwq9O067T 2B/UdbYe2QnbSw5YWe2G/P/gdOXpK1ftsqUO445q8RUbC9EovfkOGQv8ot+oJIK1Rv5k eSIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mufMPLth0blwByXxFdG0bZks7rhn3z5Y71XDyxmhENg=; b=LMboPIGzwiAMmzvGKGLB4tZx23oa2I43W6FHdPlypcyHoAiAdM5nWEpkz5BbD2E7QH p98J3BQvQZU908ZTh73qnkjkPVheMzRZ+CHhEyxkucaIEwK+6xTRMDlXJy/q43lEA+DU iJYMAmn3YsNPUp+37tctch8sWmHhaOYzTRrL7HgE2jBy1WH/cci6/a+DmYks0+vvfVgX U2d4FQdoALmblPPmIbDTeB+RNzDODCe1rDwQI1T/3WkznhQMUlIE4AUaMPdhWnuPqNn/ 3EvH2gx/7/8D4HgYiBUTzXt3dpgT+EV7Bb+B2OHXddgsGg1ifRBwo38HJmaFOFzAgjE+ umcw== X-Gm-Message-State: AEkoouuSaIF94nn9NBgRy7nRcN9Vo3oiVVhuTz/MPSJYZg5fQHABiaB1GA67yYcLLSR6u2Y2QiZMI/jbYzXXxQ== X-Received: by 10.31.107.89 with SMTP id g86mr9819189vkc.52.1471883276803; Mon, 22 Aug 2016 09:27:56 -0700 (PDT) In-Reply-To: <57BB21D0.6070601@gmx.at> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400c:c08::230 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:206756 Archived-At: --001a11478678dd7eba053aab8744 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 22, 2016 at 12:01 PM martin rudalics wrote: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > | Win 1 - Buf x | > > ---------------------------------------------- > > | Mode-line for Win 1 | > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > | Win 2 - Buf x | > > ---------------------------------------------- > > | Minibuffer | > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > (I put to white box there to mask my work stuff. If I close that windo= w, > > 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 abo= ve > > the minibuffer (so I thought earlier that the minibuffer had 2 rows; i= t > 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. =3D=3D=3D=3D=3D Error running timer =E2=80=98pdf-cache--prefetch-start=E2=80=99: (error "ep= dfinfo: No such page 0") =3D=3D=3D=3D=3D .. 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 =E2=80=98window--dump-frame=E2=80=99 = 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. --=20 Kaushal Modi --001a11478678dd7eba053aab8744 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 22= , 2016 at 12:01 PM martin rudalics <r= udalics@gmx.at> wrote:
=C2= =A0> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =C2=A0> | Win 1 - Buf x=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0> ----------------------------------------------
=C2=A0> | Mode-line for Win 1=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=C2=A0> | Win 2 - Buf x=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0> ----------------------------------------------
=C2=A0> | Minibuffer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=C2=A0>
=C2=A0> (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).
=C2=A0
=C2=A0> the missing modeline for the bottom "Win 2 - Buf x" is= created
=C2=A0> automatically.

And what else do you see now in Win 2 besides the "- Searchd" str= ing?

I see just one line and I can scro= ll that window up/down (but now I know exactly what's causing there.. c= opying Oleh to throw some light here too; more detail below).
=C2= =A0
=C2=A0> Note that the same "-Searchd" string is shown in the a= ctual
=C2=A0> window on the top right and the bottom window auto-created exact= ly above
=C2=A0> the minibuffer (so I thought earlier that the minibuffer had 2 r= ows; it was
=C2=A0> 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.=C2=A0

frame pixel: 1910 x 109= 6 =C2=A0 cols/lines: 212 x 57 =C2=A0 units: 9 x 19
frame text pix= el: 1894 x 1096 =C2=A0 cols/lines: 210 x 57
tool: 0 =C2=A0scroll:= 0/0 =C2=A0fringe: 16 =C2=A0border: 0 =C2=A0right: 0 =C2=A0bottom: 0
<= div>
#<window 9> =C2=A0 parent: nil
pixel lef= t: 0 =C2=A0 top: 0 =C2=A0 size: 1910 x 1077 =C2=A0 new: 906
char = left: 0 =C2=A0 top: 0 =C2=A0 size: 212 x 56 =C2=A0 new: 48
normal= : 1.0 x 1.0 =C2=A0 new: nil

#<window 7> =C2= =A0 parent: #<window 9>
pixel left: 0 =C2=A0 top: 0 =C2=A0 = size: 1910 x 1001 =C2=A0 new: 830
char left: 0 =C2=A0 top: 0 =C2= =A0 size: 212 x 52 =C2=A0 new: 44
normal: 1.0 x 0.929433611884865= 4 =C2=A0 new: nil

#<window 6 on Quick_Start_for= _RTL_Users_9June16.pdf> =C2=A0 parent: #<window 7>
pixel= left: 0 =C2=A0 top: 0 =C2=A0 size: 956 x 1001 =C2=A0 new: 830
ch= ar left: 0 =C2=A0 top: 0 =C2=A0 size: 106 x 52 =C2=A0 new: 44
nor= mal: 0.5 x 1.0 =C2=A0 new: nil
body pixel: 940 x 981 =C2=A0 char:= 104 x 51
width left fringe: 8 =C2=A0left margin: 0 =C2=A0right m= argin: 0
width right fringe: 8 =C2=A0scroll-bar: 0 =C2=A0divider:= 0
height header-line: 0 =C2=A0mode-line: 20 =C2=A0divider: 0

#<window 8 on Quick_Start_for_RTL_Users_9June16.or= g> =C2=A0 parent: #<window 7>
pixel left: 956 =C2=A0 top= : 0 =C2=A0 size: 954 x 1001 =C2=A0 new: 830
char left: 106 =C2=A0= top: 0 =C2=A0 size: 106 x 52 =C2=A0 new: 44
normal: 0.5 x 1.0 = =C2=A0 new: nil
body pixel: 938 x 981 =C2=A0 char: 104 x 51
=
width left fringe: 8 =C2=A0left margin: 0 =C2=A0right margin: 0
<= div>width right fringe: 8 =C2=A0scroll-bar: 0 =C2=A0divider: 0
he= ight header-line: 0 =C2=A0mode-line: 20 =C2=A0divider: 0

#<window 10 on Quick_Start_for_RTL_Users_9June16.pdf> =C2=A0 p= arent: #<window 9>
pixel left: 0 =C2=A0 top: 1001 =C2=A0 si= ze: 1910 x 76 =C2=A0 new: 76
char left: 0 =C2=A0 top: 52 =C2=A0 s= ize: 212 x 4 =C2=A0 new: 4
normal: 1.0 x 0.07056638811513463 =C2= =A0 new: nil
body pixel: 1894 x 56 =C2=A0 char: 210 x 2
width left fringe: 8 =C2=A0left margin: 0 =C2=A0right margin: 0
= width right fringe: 8 =C2=A0scroll-bar: 0 =C2=A0divider: 0
height= header-line: 0 =C2=A0mode-line: 20 =C2=A0divider: 0

#<window 4 on =C2=A0*Minibuf-0*> =C2=A0 parent: nil
pixe= l left: 0 =C2=A0 top: 1077 =C2=A0 size: 1910 x 19 =C2=A0 new: 190
char left: 0 =C2=A0 top: 56 =C2=A0 size: 212 x 1 =C2=A0 new: 10
= normal: 1.0 x 1.0 =C2=A0 new: 0
body pixel: 1894 x 19 =C2=A0 char= : 210 x 1
width left fringe: 8 =C2=A0left margin: 0 =C2=A0right m= argin: 0
width right fringe: 8 =C2=A0scroll-bar: 0 =C2=A0divider:= 0
height header-line: 0 =C2=A0mode-line: 0 =C2=A0divider: 0
=C2=A0
I think that the appearanc= e 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 e= xactly what lv.el does for creating hydras. What seems to happen is that th= e pdf-tools timer error does not allow a hydra to finish doing its job.

=3D=3D=3D=3D=3D
Error running timer =E2=80= =98pdf-cache--prefetch-start=E2=80=99: (error "epdfinfo: No such page = 0")
=3D=3D=3D=3D=3D

.. and I ha= d bound toggling debug-on-error to a hydra head (hydra package jargon).
I was able to recreate the same issue when calling any hydra.=C2=A0<= /div>
=C2=A0
=C2=A0> Please ignore that.. that bug is there but has nothing to do wit= h your
=C2=A0> recent commit.
=C2=A0> I see it on emacs 25.1 RC2 too when I end up causing a timer err= or in
=C2=A0> pdf-tools package:

I'd still want to see the output of =E2=80=98window--dump-frame=E2=80= =99 for this frame
(no fear - it doesn't reveal any buffer contents).

Thanks for the retained interest in fixing this :)=C2=A0

There are 2 things here:
- I need to figur= e out why the pdf-tools timer issue is caused. Once that is fixed, with win= dow issue should not happen as the hydras I launch will be allowed to do al= l the needed window layout cleanup.
- Hopefully Oleh gets a chanc= e to investigate the hydra/lv behavior under the timer error circumstances.=
--

Kaushal Modi

--001a11478678dd7eba053aab8744--