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: Tue, 29 Jul 2014 16:02:13 +0200 [thread overview]
Message-ID: <53D7A965.30700@gmx.at> (raw)
In-Reply-To: <83tx60fjnh.fsf@gnu.org>
> Why does it make sense to do that for TTY frames? The terminal screen
> cannot be resized from within Emacs, so the arguments for treating the
> menu bar as an add-on are not really valid in this case.
The idea is that `frame-height' should have the same semantics on all
platforms. If you think we can ignore this difference for TTY frames
I'm obviously OK with it.
> Please ask questions about what you don't understand. Having just
> completed a debugging session for bug #18112, which was all about
> assignment of TTY frame sizes, I think I can explain at least some of
> that.
>
>> Probably this assignment
>>
>> if ((FRAME_TERMCAP_P (f) && !pretend) || FRAME_MSDOS_P (f))
>> FrameCols (FRAME_TTY (f)) = new_cols;
>>
>> is completely misplaced and should be either removed or inhibited when
>> called from change_frame_size_1, that is when INHIBIT equals 5. Can you
>> tell me what this assignment is for?
>
> It cannot be removed or inhibited.
Inhibited exclusively for the case that this function is called from
change_frame_size (that is when INHIBIT equals 5).
> It was introduced to fix a bug
> (#17875). The problem is that different TTY frames on the same
> terminal can potentially have different dimensions, and OTOH FrameCols
> and FrameRows are "normally" set only at terminal initiation and in
> response to a SIGWINCH signal. These assignments take care of keeping
> FrameCols and FrameRows in sync with frame dimensions in all other
> cases, because they all go through change_frame_size.
Which means FrameCols and FrameRows always have the correct values when
entering adjust_frame_size and we shouldn't change them there. Or am I
missing something?
martin
next prev parent reply other threads:[~2014-07-29 14:02 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 [this message]
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
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=53D7A965.30700@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.