From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jan =?UTF-8?Q?Dj=C3=A4rv?= Newsgroups: gmane.emacs.bugs Subject: bug#18573: 24.3.93; set-face-attribute crashes Emacs when started with -nw Date: Wed, 1 Oct 2014 19:43:11 +0200 Message-ID: References: <5426E238.6060301@vsm.in> <5CAB16D6-ECC8-4D23-A0E2-FCEADF48C1B0@swipnet.se> <8361g6mjl8.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1412185467 14726 80.91.229.3 (1 Oct 2014 17:44:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 1 Oct 2014 17:44:27 +0000 (UTC) Cc: enquiries@vsm.in, 18573@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 01 19:44:19 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XZNwl-0003vf-Px for geb-bug-gnu-emacs@m.gmane.org; Wed, 01 Oct 2014 19:44:16 +0200 Original-Received: from localhost ([::1]:57326 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZNwl-0000xJ-Ft for geb-bug-gnu-emacs@m.gmane.org; Wed, 01 Oct 2014 13:44:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45588) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZNwd-0000wA-T8 for bug-gnu-emacs@gnu.org; Wed, 01 Oct 2014 13:44:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XZNwY-0000Nv-L9 for bug-gnu-emacs@gnu.org; Wed, 01 Oct 2014 13:44:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:37842) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZNwY-0000Np-HU for bug-gnu-emacs@gnu.org; Wed, 01 Oct 2014 13:44:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XZNwY-000743-0J for bug-gnu-emacs@gnu.org; Wed, 01 Oct 2014 13:44:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jan =?UTF-8?Q?Dj=C3=A4rv?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 01 Oct 2014 17:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18573 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 18573-submit@debbugs.gnu.org id=B18573.141218539827092 (code B ref 18573); Wed, 01 Oct 2014 17:44:01 +0000 Original-Received: (at 18573) by debbugs.gnu.org; 1 Oct 2014 17:43:18 +0000 Original-Received: from localhost ([127.0.0.1]:57639 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XZNvp-00072t-Md for submit@debbugs.gnu.org; Wed, 01 Oct 2014 13:43:18 -0400 Original-Received: from mailfe06.swip.net ([212.247.154.161]:53483 helo=swip.net) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XZNvm-00072j-Ux for 18573@debbugs.gnu.org; Wed, 01 Oct 2014 13:43:16 -0400 X-T2-Spam-Status: No, hits=-0.0 required=5.0 tests=BAYES_20 Original-Received: from hosdjarv.se (account mj138573@tele2.se [46.59.42.57] verified) by mailfe06.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 534091946; Wed, 01 Oct 2014 19:43:12 +0200 In-Reply-To: <8361g6mjl8.fsf@gnu.org> X-Mailer: Apple Mail (2.1878.6) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:93980 Archived-At: Hi. 29 sep 2014 kl. 19:18 skrev Eli Zaretskii : >> From: Jan Dj=E4rv >> Date: Sun, 28 Sep 2014 10:44:15 +0200 >> Cc: 18573@debbugs.gnu.org >>=20 >> 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: >>=20 >> #define FRAME_RES_Y(f) = \ >> (eassert (FRAME_WINDOW_P (f)), FRAME_DISPLAY_INFO (f)->resy) >>=20 >> Now, FRAME_DISPLAY_INFO for a NS compiled Emacs is >>=20 >> #define FRAME_DISPLAY_INFO(f) ((f)->output_data.ns->display_info) >>=20 >> 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. >>=20 >> The code is in xfaces.c, Finternal_set_lisp_face_attribute, around = line 3120 where it calls >> font_load_for_lface. >>=20 >> 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. >>=20 >> I think these cases should be the same, i.e. font_load_for_lface not = called for tty frames. >=20 > 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. >=20 > Is that description correct? Yes. >=20 > 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 >=20 > if (! FONT_OBJECT_P (value)) >=20 > 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. >=20 > 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.