From: martin rudalics <rudalics@gmx.at>
To: Eli Zaretskii <eliz@gnu.org>
Cc: mvoteiza@udel.edu, 18136@debbugs.gnu.org
Subject: bug#18136: 24.4.50; crash in redisplay when calling load-theme
Date: Thu, 31 Jul 2014 18:53:33 +0200 [thread overview]
Message-ID: <53DA748D.4010201@gmx.at> (raw)
In-Reply-To: <83oaw5ssuf.fsf@gnu.org>
>> But I don't really understand about `set-frame-height' and friends on a
>> TTY and what they are supposed to do. Should these be allowed to change
>> the frame size?
>
> Yes.
In the sense that the frame can get larger or smaller than the terminal
window? So we internally work with say 100 frame lines although the
terminal can display only 80? Or am I missing something?
>> Now about the
>>
>> 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);
>>
>> call in init_display. What precisely is this supposed to accomplish?
>
> Allocate the glyph matrices, at the very least, I guess.
OK. BTW doesn't adjust_frame_glyphs_for_frame_redisplay count the
menubar specially? What is
top_window_y = FRAME_TOP_MARGIN (f);
for?
>> Back to init_display and the question I asked earlier: Why should the
>> subsequent adjust_frame_size call do
>>
>> if ((FRAME_TERMCAP_P (f) && !pretend) || FRAME_MSDOS_P (f))
>> FrameRows (FRAME_TTY (f)) = new_lines;
>>
>> here?
>
> Maybe it shouldn't, when called from init_display. But we should at
> least leave an eassert there, in case we overlook something.
Can I call adjust_frame_size directly from init_display?
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.
Still it seems to me contrived to set FrameCols/FrameRows when adjusting
the sizes of a frame's windows. And setting FrameCols when called from
init_display is certainly not TRT IMHO.
> 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. BTW in an earlier mail you said that
> E.g., with your suggested semantics, what would you expect from this:
>
> emacs -Q
> M-: (frame-height) RET
> M-x menu-bar-mode RET
> M-: (frame-height) RET
>
> Would you expect to see the 2 results of frame-height identical or
> different?
>
> The current trunk displays 2 identical results, and actually resizes
> the root window to be consistent with that, so that there's an unused
> empty line below the echo area. Is that intended? It looks like a
> misfeature to me.
Where and how did you get that? I can't reproduce it here.
>> Now please tell me one thing: Which calls of change_frame_size or
>> adjust_frame_size _should_ set FrameRows or FrameCols
>
> Any calls that actually change the frame size.
Is turning off/on the TTY menubar one of them? I think not. Yet we set
FrameCols. Wouldn't it be principally cleaner if we set FrameCols and
FrameRows after calling get_tty_size only?
martin
next prev parent reply other threads:[~2014-07-31 16:53 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-29 0:36 bug#18136: 24.4.50; crash in redisplay when calling load-theme Mark Oteiza
2014-07-29 9:05 ` Eli Zaretskii
2014-07-29 10:44 ` martin rudalics
2014-07-29 12:12 ` Eli Zaretskii
2014-07-29 14:02 ` martin rudalics
2014-07-29 14:47 ` Eli Zaretskii
2014-07-29 15:41 ` martin rudalics
2014-07-29 16:31 ` Eli Zaretskii
2014-07-29 18:23 ` martin rudalics
2014-07-29 18:29 ` Eli Zaretskii
2014-07-30 16:45 ` martin rudalics
2014-07-30 17:18 ` Eli Zaretskii
2014-07-30 17:36 ` martin rudalics
2014-07-30 17:52 ` Eli Zaretskii
2014-07-31 8:49 ` martin rudalics
2014-07-31 10:52 ` Eli Zaretskii
2014-07-31 16:53 ` martin rudalics [this message]
2014-07-31 17:55 ` Eli Zaretskii
2014-08-01 8:57 ` martin rudalics
2014-08-01 12:55 ` Eli Zaretskii
2014-08-04 17:23 ` martin rudalics
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53DA748D.4010201@gmx.at \
--to=rudalics@gmx.at \
--cc=18136@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=mvoteiza@udel.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.