bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Titus von der Malsburg
Subject: bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width
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.  However, a common use case of
face-remapping-alist is to merge a new attribute into the existing
definition of a face, e.g:

  ((default (:height 1.2) default))

Moreover, the default face seems to be a special case.  If you define
face-remapping-alist as following:

  ((default (:height 1.2)))

the height attribute is merged into the existing definition of the
default face.  What this means is that the faces used in a buffer will
typically (but not necessarily) depend on the default font and thus on
the frame in which the buffer is displayed.

  Titus

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]