bug#18136: 24.4.50; crash in redisplay when calling load-theme

[martin rudalics]

> That will not work well (you can try and see yourself).  But the
> opposite, i.e. having a 80-line frame on a 100-line terminal, is quite
> usable.  In fact, some people seem to use that to have minibuffer-only
> frames on a TTY.

Weird.  Such setting gets lost immediately when the terminal window is
resized.

>    /* Add in menu bar lines, if any.  */
>    matrix_dim.height += top_window_y;

Doesn't this add an extra glyph row?

>> Can I call adjust_frame_size directly from init_display?
>
> If all the rest is a no-op, yes, why not?

You mean it must not call Lisp?

>> IIUC FrameRows is the height of the terminal window and when I change
>> the height of that window I want to change the height of the Emacs frame
>> as well via handle_window_change_signal/change_frame_size.  This means I
>> can set FrameCols where I do it now because whenever I change the size
>> of the outer frame that of the frame's windows changes too.
>
> Sorry, you lost me here.  First, you use "window" in several
> overloaded meanings, or so it seems.  And second, why are we suddenly
> talking about SIGWINCH and its handling?  This is not the scenario in
> which this bug happens.

Because adjust_frame_size has to handle SIGWINCH as well.

>> Still it seems to me contrived to set FrameCols/FrameRows when adjusting
>> the sizes of a frame's windows.
>
> How else will FrameCols/FrameRows be updated if the user calls
> set-frame-size and its ilk?

I thought that FrameCols/FrameRows store the sizes of the terminal
window.  IIUC this means that `set-frame-size' makes us lie about the
terminal sizes.

>> And setting FrameCols when called from init_display is certainly not
>> TRT IMHO.
>
> If you are sure they are already set by then, OK.  Evidently, in this
> case, the call to change_frame_size tried to decrease the frame size
> by one line, so something is still out of sync somewhere.

Obviously.

>>   > In any case, this begs the question: why do you at all call
>>   > adjust_frame_size in this case, if the frame already has the required
>>   > size?  I think the answer is that adjust_frame_size does something
>>   > else: it calls adjust_frame_glyphs.  That call is required at
>>   > init_display time for obvious reasons, but it is inside
>>   > adjust_frame_size which is only called when the frame size changes,
>>   > which sounds like a contradiction in the design.
>>
>> Think of turning off/on the menubar of a maximized frame.  In this case
>> I do not change the size of the frame either.  Yet I have to call
>> adjust_frame_glyphs.
>
> Is that supposed to be the answer to my question, or just say what I
> said in other words?

A complement to what you said.

> I can reproduce it with the current trunk on GNU/Linux where I invoke
> "emacs -Q -nw" via PuTTY.  The resize is _after_ I invoke frame-height
> the second time, which is already the sign of a problem.

Unfortunately, restoring the init_display change as you proposed earlier
by simply doing


=== modified file 'src/dispnew.c'
--- src/dispnew.c       2014-07-28 09:39:09 +0000
+++ src/dispnew.c       2014-08-01 08:23:58 +0000
@@ -6069,8 +6069,7 @@
     t->display_info.tty->top_frame = selected_frame;
     change_frame_size (XFRAME (selected_frame),
                        FrameCols (t->display_info.tty),
-                       FrameRows (t->display_info.tty)
-                      - FRAME_MENU_BAR_LINES (f), 0, 0, 1, 0);
+                       FrameRows (t->display_info.tty), 0, 0, 1, 0);

     /* Delete the initial terminal. */
     if (--initial_terminal->reference_count == 0


doesn't remove the cmcheckmagic abort here.  IUUC the problem is with
the deliberate mixture of frame and terminal sizes when using cursor
coordinates within term.c, like

          && curY (tty) == FrameRows (tty) - 1

and

      && curY (tty) + 1 == FRAME_LINES (f)

So far this can have worked only by some strange magic assuring that
FRAME_LINES always returns the same value as FrameRows.

>> Wouldn't it be principally cleaner if we set FrameCols and FrameRows
>> after calling get_tty_size only?
>
> You can't.  get_tty_size reports the _physical_ dimensions of the
> terminal screen, so it cannot support set-frame-size and its ilk,
> which leave the physical dimensions unaltered.

Does that mean `set-frame-size' should not set FrameCols/FrameRows?

I'm still too silly to understand this: Please tell me whether FrameRows
stands for the height of the terminal window as reported by get_tty_size
or for the height of the frame as set by `set-frame-size'?

martin