From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width Date: Sat, 20 Dec 2014 14:45:43 +0200 Message-ID: <838ui2sd54.fsf@gnu.org> References: <87vblbnz2u.fsf@posteo.de> <83k31rwe55.fsf@gnu.org> <87lhm772o2.fsf@posteo.de> <83h9wvwbux.fsf@gnu.org> <87bnn39cpe.fsf@posteo.de> <83a92mwau9.fsf@gnu.org> <874msu9out.fsf@posteo.de> <83vblauoh6.fsf@gnu.org> <87wq5q864m.fsf@posteo.de> <83tx0uum88.fsf@gnu.org> <87a92lmxy3.fsf@posteo.de> <837fxpue6v.fsf@gnu.org> <54945BCB.8030506@gmx.at> <83tx0rsa9e.fsf@gnu.org> <54954ACE.7050204@gmx.at> <83bnmysi2n.fsf@gnu.org> <549560B9.5070308@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1419079583 24401 80.91.229.3 (20 Dec 2014 12:46:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 20 Dec 2014 12:46:23 +0000 (UTC) Cc: 19395@debbugs.gnu.org, malsburg@posteo.de To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Dec 20 13:46:16 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 1Y2JQF-0001aZ-J1 for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Dec 2014 13:46:15 +0100 Original-Received: from localhost ([::1]:34175 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y2JQE-0006ih-P7 for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Dec 2014 07:46:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47322) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y2JQ8-0006iY-3f for bug-gnu-emacs@gnu.org; Sat, 20 Dec 2014 07:46:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y2JQ3-0001Uy-9L for bug-gnu-emacs@gnu.org; Sat, 20 Dec 2014 07:46:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42850) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y2JQ3-0001Ug-6I for bug-gnu-emacs@gnu.org; Sat, 20 Dec 2014 07:46:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Y2JQ2-0004fe-H6 for bug-gnu-emacs@gnu.org; Sat, 20 Dec 2014 07:46:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 20 Dec 2014 12:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19395 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 19395-submit@debbugs.gnu.org id=B19395.141907955017932 (code B ref 19395); Sat, 20 Dec 2014 12:46:02 +0000 Original-Received: (at 19395) by debbugs.gnu.org; 20 Dec 2014 12:45:50 +0000 Original-Received: from localhost ([127.0.0.1]:52216 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y2JPq-0004fA-38 for submit@debbugs.gnu.org; Sat, 20 Dec 2014 07:45:50 -0500 Original-Received: from mtaout24.012.net.il ([80.179.55.180]:38467) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y2JPn-0004f1-Vg for 19395@debbugs.gnu.org; Sat, 20 Dec 2014 07:45:49 -0500 Original-Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NGV00300RRDVE00@mtaout24.012.net.il> for 19395@debbugs.gnu.org; Sat, 20 Dec 2014 14:37:55 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NGV004B5SF6UZ10@mtaout24.012.net.il>; Sat, 20 Dec 2014 14:37:55 +0200 (IST) In-reply-to: <549560B9.5070308@gmx.at> X-012-Sender: halo1@inter.net.il 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:97603 Archived-At: > Date: Sat, 20 Dec 2014 12:42:49 +0100 > From: martin rudalics > CC: malsburg@posteo.de, 19395@debbugs.gnu.org > > > AFAIU, it only says so about the set-face-FOO functions, which doesn't > > include face-font. > > Here I see in "37.12.3 Face Attribute Functions" > > ... > > The following functions examine the attributes of a face. They > mostly provide compatibility with old versions of Emacs. If you don't > specify FRAME, they refer to the selected frame; `t' refers to the > default data for new frames. They return `unspecified' if the face > doesn't define any value for that attribute. If INHERIT is `nil', only > an attribute directly defined by the face is returned. If INHERIT is > non-`nil', any faces specified by its `:inherit' attribute are > considered as well, and if INHERIT is a face or a list of faces, then > they are also considered, until a specified attribute is found. To > ensure that the return value is always specified, use a value of > `default' for INHERIT. > > -- Function: face-font face &optional frame > This function returns the name of the font of face FACE. Ah, OK. That probably wants you to use the Brave New World's (face-attribute 'default :font) instead of using face-font. > > How can the current buffer be not displayed in the selected frame? > > As in > > (with-selected-frame some-frame > (with-current-buffer a-buffer-not-displayed-on-some-frame > ... Which makes it "displayed", as far as Emacs is concerned, right? IOW, for this purpose, the fact that the display engine didn't actually display the buffer doesn't matter. All we need is the frame and access to face-remapping-alist. > >> I still don't > >> understand where and how text rescaling is applied. > > > > In face-remap.el, and then in xfaces.c (search for face_remapping in > > the latter). > > This boils down to understanding the 200+ lines of merge_face_ref, at > least. What do you want to understand? In a nutshell, we go through the face-remapping-alist, and if the face is there, use the remapped face's attributes instead. > If I look at the doc-string of say `text-scale-adjust' I cannot see that > some buffer local value is mentioned although C-x C-- clearly has only a > buffer local effect here. So I obviously have to delve into the doc of > something like `face-remapping-alist' which, however, doesn't mention > any relationship of faces to frames. face-remapping-alist is applied _after_ the frame-specific face is retrieved. Does that answer your problem? > IIUC face remapping maps a default face (which may be frame specific or > not) via a scaling value (which may be buffer local or not) to another > face whose width I eventually want to retrieve via `face-font'. Does > the buffer/frame/window relationship affect that value and if so how? AFAIK, only the buffer matters, since face-remapping-alist is buffer-local.