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#16051: 24.3.50; Emacs hang - resize frame manually Date: Mon, 23 Dec 2013 19:44:33 +0100 Message-ID: <52B88491.1000903@gmx.at> References: <3eea48d4-9267-45fa-84c8-3eb9c9290558@default> <52B59B44.9060307@poczta.onet.pl> <83a9fu9r1j.fsf@gnu.org> <52B5B7EA.2080809@poczta.onet.pl> <837gay9nx2.fsf@gnu.org> <52B5CC35.10404@gmx.at> <83zjnr7bea.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1387824316 18465 80.91.229.3 (23 Dec 2013 18:45:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Dec 2013 18:45:16 +0000 (UTC) Cc: jarekczek@poczta.onet.pl, 16051@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Dec 23 19:45:21 2013 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 1VvAVE-0008Fo-GU for geb-bug-gnu-emacs@m.gmane.org; Mon, 23 Dec 2013 19:45:20 +0100 Original-Received: from localhost ([::1]:34959 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VvAVE-00032Z-2N for geb-bug-gnu-emacs@m.gmane.org; Mon, 23 Dec 2013 13:45:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49216) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VvAV4-00032N-72 for bug-gnu-emacs@gnu.org; Mon, 23 Dec 2013 13:45:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VvAUw-00071H-QF for bug-gnu-emacs@gnu.org; Mon, 23 Dec 2013 13:45:10 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:50554) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VvAUw-000714-Mk for bug-gnu-emacs@gnu.org; Mon, 23 Dec 2013 13:45:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VvAUw-0001KA-E5 for bug-gnu-emacs@gnu.org; Mon, 23 Dec 2013 13:45: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: Mon, 23 Dec 2013 18:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16051 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16051-submit@debbugs.gnu.org id=B16051.13878242845015 (code B ref 16051); Mon, 23 Dec 2013 18:45:02 +0000 Original-Received: (at 16051) by debbugs.gnu.org; 23 Dec 2013 18:44:44 +0000 Original-Received: from localhost ([127.0.0.1]:36334 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VvAUd-0001Io-Ug for submit@debbugs.gnu.org; Mon, 23 Dec 2013 13:44:44 -0500 Original-Received: from mout.gmx.net ([212.227.15.15]:59606) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VvAUb-0001If-63 for 16051@debbugs.gnu.org; Mon, 23 Dec 2013 13:44:42 -0500 Original-Received: from [62.47.63.246] ([62.47.63.246]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lj1jy-1VLHyb2irO-00dCzr for <16051@debbugs.gnu.org>; Mon, 23 Dec 2013 19:44:39 +0100 In-Reply-To: <83zjnr7bea.fsf@gnu.org> X-Provags-ID: V03:K0:4vniLPIZrSlUGh3X/m4xrimkqWOf+fU9pEoSMyZIiHZsbx0P1X2 MRv7tlorEvdmE2LkAp8PzvGTvdt1Vsq8JWWPcrMDwES8EA00p70GQb5CnLBp63Ch7FDzdPe C9U8IyqPPgwNhN/a2CnolHvpbTlD5Z5ewBeMZ5gMqkcMoGbizeVAdhMAbxe22KmqvkEPUUl bm7Nw9GdcHU6MSByQNe2g== 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:82455 Archived-At: > It turns out this bug has 3 separate parts. 2 of them are very clear > and uncontroversial, so I simply fixed them; see revision 115718 on > the trunk. After that, there are no more assertion violations like > above, and no hangs, and it is much harder to cause a redisplay loop. Thanks. - it.last_visible_x = FRAME_TOTAL_COLS (f) * FRAME_COLUMN_WIDTH (f); + it.last_visible_x = WINDOW_PIXEL_WIDTH (w); Wonderful. The effect of this was visible in the Lucid/Motif builds but since I hadn't seen it in the Windows build I didn't expect to find the cause in the toolkit independent part of the code. But is this related to the current bug? The second issue belongs in the category of things I expected to happen hoping that sooner or later you would detect and fix them. I would certainly be able to spend some time studying your fix and still not grasp it. > if (change_height_p) > { > int new_lines = ((new_height + FRAME_LINE_HEIGHT (f) - 1) > / FRAME_LINE_HEIGHT (f)); > > XSETFRAME (frame, f); > Fmodify_frame_parameters (frame, > list1 (Fcons (Qtool_bar_lines, > make_number (new_lines)))); > /* Always do that now. */ > clear_glyph_matrix (w->desired_matrix); > f->n_tool_bar_rows = nrows; > f->fonts_changed = 1; > return 1; > } > > Why does it make sense to "always do that"? Suppose new_lines is > exactly equal to the current number of canonical lines used by the > tool-bar window (it can happen even if pixel sizes are different, due > to integer truncation). Or suppose you are asking for N lines, but > don't get it because the frame is too small. Why set the > fonts_changed flag in those cases? That flag causes redisplay to give > up, abandon the current glyph matrices, and retry anew. What happens > with those endless cycles is precisely that: redisplay_tool_bar sets > the fonts_changed flag, which causes redisplay_internal to retry, > which again calls redisplay_tool_bar, which again sets the flag, > etc., ad nauseam. "Always" referred to the glyph matrix clearing part. I was completely ignorant of the fact that setting the fonts_changed flag would cause this to loop. Admittedly, I normally don't use the toolbar and so have not given it enough testing with more extreme behavior. As an aside, I have never been able to understand the purpose of the tool-bar-lines parameter. IIUC we are only supposed to read its value from Lisp but never to set it to anything but zero or one. Am I right? > If there is some reasoning behind this "always do that" logic, please > describe it. Otherwise, I propose the patch below, which cures the > problem altogether for me; if you agree, I will install it. I certainly agree :-) > As an aside, I stared for a long time at this part of > w32fns.c:x_set_tool_bar_lines (which is part of the issue, because it > is called by modify-frame-parameters, when the tool-bar-lines > parameter is changed), and I still don't get why it does what it does: > root_height = WINDOW_PIXEL_HEIGHT (XWINDOW (FRAME_ROOT_WINDOW (f))); > if (root_height - delta < unit) How would you know - it probably doesn't do anything reasonable. When we enter this part we see only the upper part of the first row of the toolbar, the rest of the toolbar, root and minibuffer window being clipped by the window manager. > { > delta = root_height - unit; > nlines = (root_height / unit) + min (1, (root_height % unit)); > } > > First, delta is recomputed, but the result is never used. More > importantly, you assign to nlines a value that is the size of the root > window _plus_ one line? Did you mean minus instead? Probably. If you have any good idea what to do here, please do it. IIUC we want to pretend that the frame has the full toolbar (probably as many rows as it has items), a one line root window and, if it's present, a one line minibuffer window. This should be robust enough to avoid a crash. But the underlying problem, namely that shrinking the width of the frame may mean that we'd have to enlarge its height, remains. Currently, our internal toolbar gets nominally larger than the containing frame. > Finally, the corresponding xfns.c implementation still works in lines, > not in pixels, as w32fns.c did before your pixelwise changes. Is this > disparity on purpose or an oversight? When I installed my changes I tested this only with the Windows and the Gtk builds. It's only now that I encountered problems with the Lucid and Motif builds. I'm working on this currently. martin