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

[Eli Zaretskii]

> From: Titus von der Malsburg <malsburg@posteo.de>
> Cc: martin rudalics <rudalics@gmx.at>, 19395@debbugs.gnu.org
> Date: Sun, 21 Dec 2014 13:14:20 +0100
> 
> On 2014-12-20 Sat 20:52, Eli Zaretskii wrote:
> >> Date: Sat, 20 Dec 2014 19:58:05 +0100
> >> From: martin rudalics <rudalics@gmx.at>
> >> CC: malsburg@posteo.de, 19395@debbugs.gnu.org
> >> 
> >>  >> IIUC this contradicts an earlier observation by Titus that
> >>  >>
> >>  >>     if the buffer in the specified window is displayed in two frames,
> >>  >>     the returned character width was always the one used in the current
> >>  >>     frame which is not necessarily the character width in the specified
> >>  >>     window (the window may be in the other frame).  This is a problem
> >>  >>     because character width can be different, if the two frames use
> >>  >>     different default fonts.
> >>  >
> >>  > I don't see any contradictions.  I said nothing about windows, only
> >>  > about frames and buffers.
> >> 
> >> His last sentence says that the outcome is dependent on the frame.  So
> >> it does not "replace" the original frame-specific face but "merge" the
> >> frame and buffer specific faces.
> >
> > No.  When a buffer is displayed that has a face in its
> > face-remapping-alist, every face in that alist is replaced by its
> > remapped face.
> 
> Yes, that's technically correct.

Actually, I stand corrected: we do merge the remapped face with the
original one.  It goes like this:

   lookup_basic_face
     -> lookup_named_face
          -> merge_face_vectors

Sorry.