GNU bug report logs - #16051
24.3.50; Emacs hang - resize frame manually

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jarekczek <at> poczta.onet.pl, 16051 <at> debbugs.gnu.org
Subject: bug#16051: 24.3.50; Emacs hang - resize frame manually
Date: Mon, 23 Dec 2013 21:02:24 +0100

> If you are right, then I'm confused: the call to
> Fmodify_frame_parameters that changes the tool-bar-lines parameter
> leads to a call to x_set_tool_bar_lines, which in turn resizes the
> tool-bar window.  And the value is certainly not always 1, I've seen
> it as large as 7.

This must be the display code which takes the deviation via the frame
parameter to communicate the new size to resize_frame_windows.  Not very
clean IMHO.

> Well, the old code simply left at least one screen line to the window,
> and if the tool bar asked for more than that, its request was not
> honored:

This is not what I see with 24.3: With emacs -Q make the frame very
narrow and shrink its height.  Here I see 3 tool-bar lines but no root
or minibuffer window.

>   delta = nlines - FRAME_TOOL_BAR_LINES (f);
>
>   /* Don't resize the tool-bar to more than we have room for.  */
>   root_window = FRAME_ROOT_WINDOW (f);
>   root_height = WINDOW_TOTAL_LINES (XWINDOW (root_window));
>   if (root_height - delta < 1)
>     {
>       delta = root_height - 1;
>       nlines = FRAME_TOOL_BAR_LINES (f) + delta;
>     }
>
>   FRAME_TOOL_BAR_LINES (f) = nlines;

I understand its meaning and also that the subsequent call to
resize_frame_windows is OK.  But, as stated above, the toolbar is not
shrunk to one line.  The change does not get propagated back to the
display engine to display less lines.  Or am I missing something?

> Translation of this to pixels is straightforward, but it looks like
> you wanted to do something different here?

I can do that translation but would rather like to understand first what
really goes on here.

>> 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.
>
> There's no crash anymore, at least not on Windows.  But doing what you
> suggest above means we will need to resize the entire frame, something
> we never did.

No.  I meant to keep the frame size fixed at some minimum value and let
the window manager do the clipping - just as it does now.

>> 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.
>
> It gets larger and is displayed only partially.  I think this is
> reasonable under these circumstances: if the user does dumb things,
> which shouldn't we let her suffer?

The problem is not that it gets larger.  The problem is that it gets
larger than the containing frame.  OTOH if Emacs thinks that it has only
one line that might be good enough for us.

martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.