From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#16923: 24.3.50; reression: `set-frame-size' loses mode line Date: Fri, 07 Mar 2014 18:48:05 +0100 Message-ID: <531A0655.5040400@gmx.at> References: <53143D5C.7020000@gmx.at> <5314CBE1.6050905@gmx.at> <04dda5ae-8b70-42f5-ae09-c1d05ebc9297@default> <5314DB5D.50709@gmx.at> <29b76228-778a-4aea-8fe4-5abedb5b6795@default> <531589F3.1050300@gmx.at> <70615a8e-3923-40c3-bfbc-af0a305cd6df@default> <5316D1B5.8040801@gmx.at> <53176AF2.9010800@gmx.at> <53177AEF.9050106@gmx.at> <3f31643f-2638-4ada-8dc4-b3069f3a82fc@default> <531780D7.6070109@gmx.at> <291bd9d5-923f-440a-821a-06f585557e67@default> <5318AFD9.4000208@gmx.at> <8be91728-fcea-4e74-afff-db6a55b52985@default> <5318C478.1090007@gmx.at> <0f1c6cae-f9cd-4a2b-a662-bcc4116daafc@default> <5318E810.7000705@gmx.at> <531977B2.8030109@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1394214553 1735 80.91.229.3 (7 Mar 2014 17:49:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 7 Mar 2014 17:49:13 +0000 (UTC) Cc: 16923@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Mar 07 18:49:22 2014 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 1WLytb-00018u-8D for geb-bug-gnu-emacs@m.gmane.org; Fri, 07 Mar 2014 18:49:19 +0100 Original-Received: from localhost ([::1]:37661 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WLyta-0005PV-TP for geb-bug-gnu-emacs@m.gmane.org; Fri, 07 Mar 2014 12:49:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51204) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WLytR-0005Om-8i for bug-gnu-emacs@gnu.org; Fri, 07 Mar 2014 12:49:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WLytL-00079E-3F for bug-gnu-emacs@gnu.org; Fri, 07 Mar 2014 12:49:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53933) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WLytK-000797-Vh for bug-gnu-emacs@gnu.org; Fri, 07 Mar 2014 12:49:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WLytK-0005yt-Bk for bug-gnu-emacs@gnu.org; Fri, 07 Mar 2014 12:49:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 07 Mar 2014 17:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16923 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 16923-submit@debbugs.gnu.org id=B16923.139421449322915 (code B ref 16923); Fri, 07 Mar 2014 17:49:02 +0000 Original-Received: (at 16923) by debbugs.gnu.org; 7 Mar 2014 17:48:13 +0000 Original-Received: from localhost ([127.0.0.1]:55115 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WLysW-0005xW-Lq for submit@debbugs.gnu.org; Fri, 07 Mar 2014 12:48:13 -0500 Original-Received: from mout.gmx.net ([212.227.15.15]:53861) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WLysS-0005xE-V7 for 16923@debbugs.gnu.org; Fri, 07 Mar 2014 12:48:10 -0500 Original-Received: from [62.46.209.190] ([62.46.209.190]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M0hT0-1XBKuX1XQ6-00uuQE; Fri, 07 Mar 2014 18:48:07 +0100 In-Reply-To: X-Provags-ID: V03:K0:TvB+HkJbT5ZTLWfJi2PuEIROgHUUByUnE8UX33doqYA7OyewUXl 2N/8wSb6AYRMIkXXQB1cTKF3AQRIkkj/j+JrKKZOKEHjoq4DuaeeqVATBpXcv253S5umPMS YOAfqpxnEWSVxj9NeU6/xqHjttiFWgD+tIYWdpXwTgTyPr5uvc/2IfdnBjcVdOX9ypgbz6l 650JM5CCZXvdH39ux5INg== 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: 140.186.70.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:86628 Archived-At: > I set border-width to 10 and internal to 15. First, some of the times > when the mode line would have disappeared it did not do so. Second, > it did still do so sometimes - almost disappeared, that is. In the > latter case, what I saw (attached) was that, instead, part of the mode > line disappeared, and there was no bottom border. Good. IIUC this shows that the display engine works correctly. It draws the mode line but somehow it gets clipped together with the internal border. > It seems we're getting somewhere now. It will be just a sobering experience when we're there at last. >> (3) Try to enhance `window--dump-frame' in a way that it does not erase >> its buffer and call it several times, immediately before and after >> you ask for a frame size change in `fit-frame'. Moreover, you could >> add two lines to it with a suitable informatory text to display the >> values returned by >> >> (w32-frame-rect frame) >> (w32-frame-rect frame t) >> >> These are Windows specific so I can't include them in the >> `window--dump-frame' version that comes with Emacs. > > Attached also. When fit-frame was called, it printed ------------. > Then it called `window--dump-frame' 3 times. Then it fit the frame. > Then it called `window--dump-frame' 3 times again. `window--dump-frame' > inserted a form feed, then the data. It seems easy to spot the problem - it should be w32-rect: (0 0 635 912), (0 0 627 832) ... w32-rect: (0 0 635 828), (0 0 627 748) ... w32-rect: (0 0 707 912), (0 0 699 856) <--- here ... w32-rect: (0 0 635 912), (0 0 627 832) The difference between the height of the outer rectangle (which includes title and menu bar and decorations) and the client rectangle shrinks from 80 to 56 pixels. I suppose that all parts exclusively in the outer rectangle (title, menu bar, ...) are still here as before (are they????) which means that there are 24 pixels less for the client rectangle and Windows partly draws the frame decoration over it and clips the rest. Prepare a function to print the difference of the (nth 3) of the two `w32-frame-rect' calls in the echo area of a second frame, bind it to a key, and you should see that whenever the modeline is absent that value is 56 while otherwise it is 80. Note that `w32-frame-rect' is purely build from Windows API calls - that is, the raw values are provided by Windows and Emacs only converts them to coordinates. So at first sight this looks like a Windows bug. Windows should never return another difference unless, for example, the menu bar wraps. >> It looks like a timing error where Emacs and Windows have different >> conceptions about the size of the Emacs frame. Maybe locally binding >> `w32-enable-frame-resize-hack' to nil around the `fit-frame' calls >> would help. > > Actually, that does seem to help. It seems to solve the problem. > Let me know, after looking over all of this information, whether you > think something can be or needs to be fixed on the Emacs side for > this bug, or whether I should just wrap such a binding around the > body of `fit-frame'. It's a fragile fix. But I have no better solution at the moment. > FWIW: Dunno whether it is related, but I have also seen this recently: > Library pp-c-l.el shows a form-feed char in a pretty way, as shown here: > http://www.emacswiki.org/cgi-bin/wiki/PrettyControlL. This is > still the case in general, but sometimes when a file with form feeds > is first visited they appear normally, i.e., as ^L. Even hitting `C-l' > does not cause their proper display. Eventually they are displayed OK. > > Perhaps Emacs redisplay is now happening less than was the case before? > > Dunno whether this is at all related to bug #16923 (which does not > regain the proper display of the mode line at all). FWIW this is completely unrelated. martin