bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 20 Dec 2014 12:42:49 +0100
> From: martin rudalics <rudalics@gmx.at>
> 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.