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 10:49:11 +0200 [thread overview]
Message-ID: <53DA0307.6040004@gmx.at> (raw)
In-Reply-To: <831tt2u428.fsf@gnu.org>
> I thought we agreed that TTY frames should include the menu bar in
> their height, and therefore change_frame_size should not have its 3rd
> argument decreased by FRAME_MENU_BAR_LINES for TTY frames.
I'm afraid that doing so might run into problems in adjust_frame_size.
Basically, the flow of things for turning on/off menubars should be as
follows where "outer frame" stands for what Windows calls the client
area and what on a TTY would stand for the screen space within a
terminal window allotted to Emacs.
(1) The user decides to enable/disable the menubar. The request is
passed to adjust_frame_size.
(2) adjust_frame_size (or better, frame_inhibit_resize) decides that
we're on TTY and therefore the outer frame should _not_ be resized.
Thus inhibit_horizontal and inhibit_vertical should be both true
after frame_inhibit_resize has been called. This means that
removing the menu bar must be handled internally by calling
resize_frame_windows to either enlarge or shrink the root window by
the menubar line.
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? If not we should assure that inhibit_horizontal and
inhibit_vertical are always true (regardless of the INHIBIT argument) on
TTYs.
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?
Note one thing: change_frame_size is just a relay to detect whether
applying (Emacs-)window changes and running Lisp is safe in the current
state. If it is not, it simply waits. Otherwise, it passes all
information to adjust_frame_size with INHIBIT set to 5 which means that
the size of the outer frame has been set already and adjust_frame_size
should only care about how to handle these sizes internally by resizing
(Emacs-)windows appropriately.
Now what does init_display? IIUC it just gets the height and width
values from t->display_info.tty and passes them on to change_frame_size.
That is, the outer frame sizes are set and adjust_frame_size has only to
deal with resizing the (Emacs-)windows corectly. This is done by
setting the new height of these windows from the height of the outer
frame via
new_windows_height = (new_pixel_height
- FRAME_TOP_MARGIN_HEIGHT (f)
- 2 * FRAME_INTERNAL_BORDER_WIDTH (f));
where new_pixel_height was earlier calculated from new_text_height as
new_pixel_height = ((inhibit_vertical && (inhibit < 5))
? old_pixel_height
: max (FRAME_TEXT_TO_PIXEL_HEIGHT (f, new_text_height),
min_windows_height
+ FRAME_TOP_MARGIN_HEIGHT (f)
+ 2 * FRAME_INTERNAL_BORDER_WIDTH (f)));
where new_text_height is the normalized value passed to
adjust_frame_size via the HEIGHT argument. This sounds contrived (why
don't I call adjust_frame_size directly with the size of the outer
frame?) but note that adjust_frame_size is more often called from inside
Emacs and there we don't care about the outer frame (on GTK we certainly
don't).
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? IIUC this _has_ already been set correctly when calling
change_frame_size and so should not be set here any more. Agreed?
Now please tell me one thing: Which calls of change_frame_size or
adjust_frame_size _should_ set FrameRows or FrameCols and how can
I distinguish them?
martin
next prev parent reply other threads:[~2014-07-31 8:49 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 [this message]
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=53DA0307.6040004@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.