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

[martin rudalics]

> Ah, OK.  That probably wants you to use the Brave New World's
>
>     (face-attribute 'default :font)
>
> instead of using face-font.

OK.  So let's do without Huxley.

>>   > 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?

You mean as far as the Emacs display engine is concerned, right?  But
the caller of `face-font' doesn't know that the display engine operates
on the current buffer regardless of whether it is displayed or not.

> 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.

I can only guess - are the following statements correct wrt to display?

(1) When two characters have the same face they are identic in their
    appearance on screen.

(2) When two characters have a different appearance on screen they have
    different faces.

For me it's difficult to discriminate the usage of the term "face" when
programming Elisp from the usage of the term "face" when Emacs displays
a character.

> face-remapping-alist is applied _after_ the frame-specific face is
> retrieved.  Does that answer your problem?

What means "applied"?  Is it merged or does it replace the
frame-specific face?

>> 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.

It's doc-string says

  If this variable is made buffer-local, the face remapping takes effect
  only in that buffer.

martin