From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.bugs Subject: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize Date: Fri, 28 Aug 2015 08:19:29 +0000 Message-ID: References: <83k2skhhz1.fsf@gnu.org> <55DB5D3E.1000706@gmx.at> <83vbc4fsjd.fsf@gnu.org> <55DC1856.7000501@gmx.at> <83pp2bfln1.fsf@gnu.org> <55DD662A.8080201@gmx.at> <83si765aqv.fsf@gnu.org> <55DEC2DB.9080800@gmx.at> <83a8tc6988.fsf@gnu.org> <55DF4FF3.1020603@gmx.at> <55E015E3.2050409@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b10c88924fc44051e5abef8 X-Trace: ger.gmane.org 1440750026 4658 80.91.229.3 (28 Aug 2015 08:20:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 28 Aug 2015 08:20:26 +0000 (UTC) Cc: 21333@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Aug 28 10:20:17 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZVEtU-0004OW-0c for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Aug 2015 10:20:16 +0200 Original-Received: from localhost ([::1]:46613 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVEtT-0004PL-F7 for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Aug 2015 04:20:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57128) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVEtM-0004MN-Gl for bug-gnu-emacs@gnu.org; Fri, 28 Aug 2015 04:20:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZVEtI-0001P1-Gn for bug-gnu-emacs@gnu.org; Fri, 28 Aug 2015 04:20:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48559) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVEtI-0001OJ-Cg for bug-gnu-emacs@gnu.org; Fri, 28 Aug 2015 04:20:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZVEtH-0000aG-At for bug-gnu-emacs@gnu.org; Fri, 28 Aug 2015 04:20:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 28 Aug 2015 08:20:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21333 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21333-submit@debbugs.gnu.org id=B21333.14407499732205 (code B ref 21333); Fri, 28 Aug 2015 08:20:03 +0000 Original-Received: (at 21333) by debbugs.gnu.org; 28 Aug 2015 08:19:33 +0000 Original-Received: from localhost ([127.0.0.1]:40769 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVEsm-0000ZV-T2 for submit@debbugs.gnu.org; Fri, 28 Aug 2015 04:19:33 -0400 Original-Received: from mail-ig0-f171.google.com ([209.85.213.171]:36648) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVEsk-0000ZL-4D for 21333@debbugs.gnu.org; Fri, 28 Aug 2015 04:19:30 -0400 Original-Received: by igcse8 with SMTP id se8so13293983igc.1 for <21333@debbugs.gnu.org>; Fri, 28 Aug 2015 01:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c6ZWfcNMzo7gKp/wy+CELoG512pciwib8sTB6KiOAHY=; b=J30AzW87LeqqsQrS6fhAk9RVOJECBlavOlWcsvrazAiG6GT+enhEZn52MgYf6tET/A kWf8pclrfKoXWT9Yoc7kbrmLY2vD4RpBrynKt7IM53vZky0H7joenWeBXcGeQlh3xRzz 9lAVFaXPMytlbgVkuxduEH8vsfrcQgrFLJGY5mvfWBEj4dcdJ0OJZAIM+IItG+QbW24J 6T/UNbjyRj4LcMsoafSosLoul1ZMEuvpH8p6CEvA9hZTe5afYakC+CWczGFGH2YV3/ER evL9NTSoRUImt+YIkjUvQQDwIn2bMFH257PUNgWChsg325xlouKainT6b7D+spkiHQlC 8BjA== X-Received: by 10.50.97.33 with SMTP id dx1mr2125357igb.1.1440749969536; Fri, 28 Aug 2015 01:19:29 -0700 (PDT) Original-Received: by 10.79.78.66 with HTTP; Fri, 28 Aug 2015 01:19:29 -0700 (PDT) In-Reply-To: <55E015E3.2050409@gmx.at> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:105904 Archived-At: --047d7b10c88924fc44051e5abef8 Content-Type: text/plain; charset=UTF-8 On Fri, Aug 28, 2015 at 8:03 AM, martin rudalics wrote: > >> FWIW here resizing a window "manually" makes the mini-window "go normal" > >> first. > > > > Strange, that doesn't work here. Are you using the echo area or the > > minibuffer to test? I'm using the minibuffer. > > It goes back to normal in the echo area but leaves the minibuffer window > alone as you say. I had assumed "go normal" meant "shrink back to normal size", which is true for the echo area but not the minibuffer. > >> Resizing the frame leaves the mini-window alone. > >> > > ...which means they'll be in an inconsistent state afterwards, having > been > > resized while the mini-window was enlarged. > > Can you tell me more about this inconsistency? > Well, first, to clarify, I was talking about unpatched Emacs, and using window-size-change-functions in an attempt to catch window size changes. 1. window at 80x24, mini-window at 1 line, window thinks it's 80x24. Everything okay. 2. mini-window grows to 2 lines 3. window at 80x23, mini-window at 2 lines, window thinks it's 80x24. Inconsistent, but temporary. 4. user resizes window to 79x23. size-change-functions called. 5. window at 79x23, mini-window at 2 lines, window thinks it's 79x23. Everything okay again. 6. mini-window shrinks. 7. window at 79x24, mini-window at 1 line, window thinks it's 79x23. Permanent inconsistency. Am I missing something here? Pip --047d7b10c88924fc44051e5abef8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Aug 28, 2015 at 8:03 AM, martin rudalics <rudalics@gmx.at> wrote:
>> FWIW h= ere resizing a window "manually" makes the mini-window "go n= ormal"
>> first.
>
> Strange, that doesn't work here. Are you using the echo area or th= e
> minibuffer to test? I'm using the minibuffer.

 It goes back to normal in the echo area but leaves the minibuffer window alone as you say.

I had assumed "go no= rmal" meant "shrink back to normal size", which is true for = the echo area but not the minibuffer.
=C2=A0
>>=C2=A0 =C2=A0 Resizing the fra= me leaves the mini-window alone.
>>
> ...which means they'll be in an inconsistent state afterwards, hav= ing been
> resized while the mini-window was enlarged.

 Can you tell me more about this inconsistency?

Well, first, to c= larify, I was talking about unpatched Emacs, and using window-size-change-f= unctions in an attempt to catch window size changes.

1. w= indow at 80x24, mini-window at 1 line, window thinks it's 80x24. Everyt= hing okay.
2. mini-window grows to 2 lines
3. w= indow at 80x23, mini-window at 2 lines, window thinks it's 80x24. Incon= sistent, but temporary.
4. user resizes window to 79x23. size= -change-functions called.
5. window at 79x23, mini-window at = 2 lines, window thinks it's 79x23. Everything okay again.
6. mini-window shrinks.
7. window at 79x24, mini-window at 1= line, window thinks it's 79x23. Permanent inconsistency.

=
Am I missing something here?

=
Pip
--047d7b10c88924fc44051e5abef8--