From: "Jan Djärv" <jan.h.d@swipnet.se>
To: Eli Zaretskii <eliz@gnu.org>
Cc: enquiries@vsm.in, 18573@debbugs.gnu.org
Subject: bug#18573: 24.3.93; set-face-attribute crashes Emacs when started with -nw
Date: Wed, 1 Oct 2014 19:43:11 +0200 [thread overview]
Message-ID: <DAA564B7-9D0C-4FCC-8CE2-6B77D2BDEF31@swipnet.se> (raw)
In-Reply-To: <8361g6mjl8.fsf@gnu.org>
Hi.
29 sep 2014 kl. 19:18 skrev Eli Zaretskii <eliz@gnu.org>:
>> From: Jan Djärv <jan.h.d@swipnet.se>
>> Date: Sun, 28 Sep 2014 10:44:15 +0200
>> Cc: 18573@debbugs.gnu.org
>>
>> This seems to be a generic error in xfaces.c. It tries to load a font without checking the type
>> of frame. The type is tty, but it tries to load a font anyway, and eventually ends up in (font.c) font_pixel_size, which does:
>>
>> #define FRAME_RES_Y(f) \
>> (eassert (FRAME_WINDOW_P (f)), FRAME_DISPLAY_INFO (f)->resy)
>>
>> Now, FRAME_DISPLAY_INFO for a NS compiled Emacs is
>>
>> #define FRAME_DISPLAY_INFO(f) ((f)->output_data.ns->display_info)
>>
>> but the frame is not an NS frame, it is a tty frame, so bad things happen.
>> It is the same for X, but there it just happens to return a nonsense value, so the code continues without crashing, and eventually discovers that there are no font dirvers and the load font fails.
>>
>> The code is in xfaces.c, Finternal_set_lisp_face_attribute, around line 3120 where it calls
>> font_load_for_lface.
>>
>> The code in question is not called if compiled for a tty (#ifdef:ed out), but it is called when the frame is a tty frame on a non-tty compiled Emacs.
>>
>> I think these cases should be the same, i.e. font_load_for_lface not called for tty frames.
>
> I believe this happens when internal-set-lisp-face-attribute is
> called with its FRAME argument t, meaning change the default for new
> (i.e. future) frames. Since the code needs a frame, it just uses the
> selected frame, which in this case happens to be a TTY frame.
>
> Is that description correct?
Yes.
>
> If so, the question is how to fix this. If we simply do nothing when
> the selected frame is a TTY frame, and then create a GUI frame at some
> future point, will the new default take effect? If it will, then I
> agree that the code under this condition
>
> if (! FONT_OBJECT_P (value))
>
> should not be executed when the selected frame is a TTY frame.
If this code is not run for the initial tty frame, then a GUI frame made later with make-frame-on-display does not get this font. The face is not changed for future frames.
>
> But if this doesn't work, then what are our alternatives? We could
> loop over all the frames looking for a GUI frame, and use that. But
> what if there's no such frame? Signal an error?
There is a fundamental error here. Emacs allows specifying face attributes for future GUI frames when only non-GUI frames exists. But those attributes requires GUI frames to be realized.
We are missing a "lazy" realization that only saves the text version of the attribute and realizes only when an apropriate frame is available.
For now I comitted the "wont crash" solution (don't execute the code for tty frames) in the emacs 24 branch. No error is signalled and no looping is done to find a GUI frame. I'm not sure if we should do that.
Jan D.
next prev parent reply other threads:[~2014-10-01 17:43 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-27 16:13 bug#18573: 24.3.93; set-face-attribute crashes Emacs on OS X 10.9.4 enquiries
2014-09-28 8:44 ` bug#18573: 24.3.93; set-face-attribute crashes Emacs when started with -nw Jan Djärv
2014-09-28 12:24 ` enquiries
2014-10-01 16:49 ` Glenn Morris
2014-10-01 17:55 ` Stefan Monnier
2014-09-29 17:18 ` Eli Zaretskii
2014-09-29 17:34 ` enquiries
2014-10-01 17:43 ` Jan Djärv [this message]
2014-10-01 17:49 ` Eli Zaretskii
2014-10-01 18:11 ` Jan Djärv
2014-10-01 18:16 ` Eli Zaretskii
2019-09-26 20:57 ` Stefan Kangas
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=DAA564B7-9D0C-4FCC-8CE2-6B77D2BDEF31@swipnet.se \
--to=jan.h.d@swipnet.se \
--cc=18573@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=enquiries@vsm.in \
/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.