* buffer-face-set changes the fringe, is it a bug? @ 2020-07-05 8:56 Gregory Heytings via Emacs development discussions. 2020-07-05 10:50 ` Eli Zaretskii 0 siblings, 1 reply; 29+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-07-05 8:56 UTC (permalink / raw) To: emacs-devel Hi list, Is the following behavior expected, or is it a bug? (set-face-attribute 'fringe nil :background "red") (let ((o (make-overlay 0 1)) (s "_")) (put-text-property 0 1 'display '(left-fringe question-mark) s) (overlay-put o 'after-string s)) This puts a question mark in the left fringe. At least on Emacs 26.3 (started with emacs -Q), after: (buffer-face-set '(:background "yellow")) the background of the buffer *and* the question mark in the fringe become yellow. I would have expected that the background of the question mark would still be red. Gregory ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: buffer-face-set changes the fringe, is it a bug? 2020-07-05 8:56 buffer-face-set changes the fringe, is it a bug? Gregory Heytings via Emacs development discussions. @ 2020-07-05 10:50 ` Eli Zaretskii 2020-07-05 12:43 ` Gregory Heytings via Emacs development discussions. 0 siblings, 1 reply; 29+ messages in thread From: Eli Zaretskii @ 2020-07-05 10:50 UTC (permalink / raw) To: Gregory Heytings, Gregory Heytings via Emacs development discussions., emacs-devel On July 5, 2020 11:56:00 AM GMT+03:00, "Gregory Heytings via Emacs development discussions." <emacs-devel@gnu.org> wrote: > > Hi list, > > Is the following behavior expected, or is it a bug? > > (set-face-attribute 'fringe nil :background "red") > (let ((o (make-overlay 0 1)) (s "_")) > (put-text-property 0 1 'display '(left-fringe question-mark) s) > (overlay-put o 'after-string s)) > > This puts a question mark in the left fringe. At least on Emacs 26.3 > (started with emacs -Q), after: > > (buffer-face-set '(:background "yellow")) > > the background of the buffer *and* the question mark in the fringe > become > yellow. I would have expected that the background of the question > mark > would still be red. > > Gregory You are assuming that 'display' property that draws on the fringe automatically uses the 'fringe' face? But that's not how this property works: it uses the 'default' face (and thus is subject to face remapping). To use another face, you need to specify it in the 'left-fringe' form, see the ELisp manual for the details. IOW, this is not a bug. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: buffer-face-set changes the fringe, is it a bug? 2020-07-05 10:50 ` Eli Zaretskii @ 2020-07-05 12:43 ` Gregory Heytings via Emacs development discussions. 2020-07-05 15:32 ` Eli Zaretskii 0 siblings, 1 reply; 29+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-07-05 12:43 UTC (permalink / raw) To: emacs-devel > >> Is the following behavior expected, or is it a bug? >> >> (set-face-attribute 'fringe nil :background "red") >> (let ((o (make-overlay 0 1)) (s "_")) >> (put-text-property 0 1 'display '(left-fringe question-mark) s) >> (overlay-put o 'after-string s)) >> >> This puts a question mark in the left fringe. At least on Emacs 26.3 >> (started with emacs -Q), after: >> >> (buffer-face-set '(:background "yellow")) >> >> the background of the buffer *and* the question mark in the fringe >> become yellow. I would have expected that the background of the >> question mark would still be red. >> >> Gregory > > You are assuming that 'display' property that draws on the fringe > automatically uses the 'fringe' face? But that's not how this property > works: it uses the 'default' face (and thus is subject to face > remapping). > OK, so one should use: (put-text-property 0 1 'display '(left-fringe question-mark fringe) s) > > To use another face, you need to specify it in the 'left-fringe' form, > see the ELisp manual for the details. > In fact the manual is not as clear as you think, it states (see https://www.gnu.org/software/emacs/manual/html_node/elisp/Fringe-Bitmaps.html ): (fringe bitmap [face]) The optional face names a face whose foreground color is used to display the bitmap; this face is automatically merged with the fringe face. For me this means that the fringe face is used to display the bitmaps in the fringe, except the :foreground property which can optionally be imported from another face. What actually happens it that the default face is used, and that its properties can ben overriden with the :foreground and :background properties of another face. So I do think this is a bug, either in the manual or in the code. Gregory ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: buffer-face-set changes the fringe, is it a bug? 2020-07-05 12:43 ` Gregory Heytings via Emacs development discussions. @ 2020-07-05 15:32 ` Eli Zaretskii 2020-07-05 16:25 ` Gregory Heytings via Emacs development discussions. 2020-07-06 12:22 ` Gregory Heytings via Emacs development discussions. 0 siblings, 2 replies; 29+ messages in thread From: Eli Zaretskii @ 2020-07-05 15:32 UTC (permalink / raw) To: Gregory Heytings; +Cc: emacs-devel > Date: Sun, 5 Jul 2020 14:43:46 +0200 (CEST) > From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org> > > OK, so one should use: > > (put-text-property 0 1 'display '(left-fringe question-mark fringe) s) Yes, if you want to get the 'fringe' face. > In fact the manual is not as clear as you think, it states (see https://www.gnu.org/software/emacs/manual/html_node/elisp/Fringe-Bitmaps.html ): > > (fringe bitmap [face]) > > The optional face names a face whose foreground color is used to display > the bitmap; this face is automatically merged with the fringe face. > > For me this means that the fringe face is used to display the bitmaps in > the fringe, except the :foreground property which can optionally be > imported from another face. Thanks, I clarified the meaning of FACE in that case. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: buffer-face-set changes the fringe, is it a bug? 2020-07-05 15:32 ` Eli Zaretskii @ 2020-07-05 16:25 ` Gregory Heytings via Emacs development discussions. 2020-07-05 16:40 ` Eli Zaretskii 2020-07-06 12:22 ` Gregory Heytings via Emacs development discussions. 1 sibling, 1 reply; 29+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-07-05 16:25 UTC (permalink / raw) To: emacs-devel > >> In fact the manual is not as clear as you think, it states (see https://www.gnu.org/software/emacs/manual/html_node/elisp/Fringe-Bitmaps.html ): >> >> (fringe bitmap [face]) >> >> The optional face names a face whose foreground color is used to >> display the bitmap; this face is automatically merged with the fringe >> face. >> >> For me this means that the fringe face is used to display the bitmaps >> in the fringe, except the :foreground property which can optionally be >> imported from another face. > > Thanks, I clarified the meaning of FACE in that case. > Okay, the meaning is clear now. But, IMO, it would be better to change this behavior as follows: "The optional @var{face} names a face whose foreground and background colors are to be used to display the bitmap; this face is automatically merged with the @code{fringe} face. If @var{face} is omitted, that means to use the *@code{fringe}* face." I at least would expect that the default behavior when displaying something in the fringe would be to use the fringe face. It is then still possible to use the 'default' face if one wishes to do so (but why would one wish to do this?). Apparently this change is possible without modifying any of the files in the "lisp" directory. Gregory ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: buffer-face-set changes the fringe, is it a bug? 2020-07-05 16:25 ` Gregory Heytings via Emacs development discussions. @ 2020-07-05 16:40 ` Eli Zaretskii 2020-07-05 16:59 ` Gregory Heytings via Emacs development discussions. 0 siblings, 1 reply; 29+ messages in thread From: Eli Zaretskii @ 2020-07-05 16:40 UTC (permalink / raw) To: Gregory Heytings; +Cc: emacs-devel > Date: Sun, 5 Jul 2020 18:25:33 +0200 (CEST) > From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org> > > > Thanks, I clarified the meaning of FACE in that case. > > > > Okay, the meaning is clear now. But, IMO, it would be better to change > this behavior as follows: > > "The optional @var{face} names a face whose foreground and background > colors are to be used to display the bitmap; this face is automatically > merged with the @code{fringe} face. If @var{face} is omitted, that means > to use the *@code{fringe}* face." > > I at least would expect that the default behavior when displaying > something in the fringe would be to use the fringe face. IMO, you are looking at this feature from the wrong angle. This is a "replacing" 'display' property that covers some buffer text or overlay string, and is displayed instead of that buffer text or overlay string. Therefore, the natural source of the face information is the face of the text which is covered by the 'display' property, not the face of the place where the bitmap is drawn. In any case, this behavior is very old, so changing it is quite out of the question. Especially since having the behavior you consider to be a better one is so easy. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: buffer-face-set changes the fringe, is it a bug? 2020-07-05 16:40 ` Eli Zaretskii @ 2020-07-05 16:59 ` Gregory Heytings via Emacs development discussions. 2020-07-05 17:24 ` Eli Zaretskii 0 siblings, 1 reply; 29+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-07-05 16:59 UTC (permalink / raw) To: emacs-devel > >> Okay, the meaning is clear now. But, IMO, it would be better to change >> this behavior as follows: >> >> "The optional @var{face} names a face whose foreground and background >> colors are to be used to display the bitmap; this face is automatically >> merged with the @code{fringe} face. If @var{face} is omitted, that >> means to use the *@code{fringe}* face." >> >> I at least would expect that the default behavior when displaying >> something in the fringe would be to use the fringe face. > > IMO, you are looking at this feature from the wrong angle. This is a > "replacing" 'display' property that covers some buffer text or overlay > string, and is displayed instead of that buffer text or overlay string. > Therefore, the natural source of the face information is the face of the > text which is covered by the 'display' property, not the face of the > place where the bitmap is drawn. > I don't understand. The left-fringe and right-fringe display properties are there to display something in the fringe, not to change the way the text to which they are attached is displayed. So why would the natural source of information be the face of the text? > > In any case, this behavior is very old, so changing it is quite out of > the question. Especially since having the behavior you consider to be a > better one is so easy. > Okay, this makes sense. Thanks for your attention. Gregory ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: buffer-face-set changes the fringe, is it a bug? 2020-07-05 16:59 ` Gregory Heytings via Emacs development discussions. @ 2020-07-05 17:24 ` Eli Zaretskii 0 siblings, 0 replies; 29+ messages in thread From: Eli Zaretskii @ 2020-07-05 17:24 UTC (permalink / raw) To: Gregory Heytings; +Cc: emacs-devel > Date: Sun, 5 Jul 2020 18:59:23 +0200 (CEST) > From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org> > > I don't understand. The left-fringe and right-fringe display properties > are there to display something in the fringe, not to change the way the > text to which they are attached is displayed. So why would the natural > source of information be the face of the text? Because that's how these properties work in all other cases, when they display in the text area. The fact that this one draws on the fringe is just a peculiarity. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: buffer-face-set changes the fringe, is it a bug? 2020-07-05 15:32 ` Eli Zaretskii 2020-07-05 16:25 ` Gregory Heytings via Emacs development discussions. @ 2020-07-06 12:22 ` Gregory Heytings via Emacs development discussions. 2020-07-06 16:41 ` Eli Zaretskii 1 sibling, 1 reply; 29+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-07-06 12:22 UTC (permalink / raw) To: emacs-devel > >> In fact the manual is not as clear as you think, it states (see https://www.gnu.org/software/emacs/manual/html_node/elisp/Fringe-Bitmaps.html ): >> >> (fringe bitmap [face]) >> >> The optional face names a face whose foreground color is used to >> display the bitmap; this face is automatically merged with the fringe >> face. >> >> For me this means that the fringe face is used to display the bitmaps >> in the fringe, except the :foreground property which can optionally be >> imported from another face. > > Thanks, I clarified the meaning of FACE in that case. > Sorry to come back to this, but on a second thought the documentation is still not correct: The optional @var{face} names a face whose foreground and background colors are to be used to display the bitmap; this face is automatically merged with the @code{fringe} face. If @var{face} is omitted, that means to use the @code{default} face. If this were true, then the following two snippets should give the same result: (set-face-attribute 'fringe nil :background "red" :foreground "blue") (let ((o (make-overlay 0 1)) (s "_")) (put-text-property 0 1 'display '(left-fringe question-mark) s) (overlay-put o 'after-string s)) (set-face-attribute 'fringe nil :background "red" :foreground "blue") (let ((o (make-overlay 0 1)) (s "_")) (put-text-property 0 1 'display '(left-fringe question-mark default) s) (overlay-put o 'after-string s)) They do not, the first one displays the question mark in blue on a red background, the second one in black on a white background. To summarize, with: (set-face-attribute 'fringe nil :background "red" :foreground "blue") (let ((o (make-overlay 0 1)) (s "_")) (put-text-property 0 1 'display '(left-fringe question-mark [1]) s) (overlay-put o 'after-string s)) [2] (buffer-face-set '(:background "yellow" :foreground "red")) [3] value in [1]: | effect after [2]: | effect after [3]: (nothing) | blue ? on red bg | red ? on yellow bg fringe | blue ? on red bg | blue ? on red bg default | black ? on white bg | red ? on yellow bg So it seems that it's only when a face remapping takes place that an omitted face in [1] means using the default face. Before the face remapping takes place, the fringe face is used instead. Gregory ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: buffer-face-set changes the fringe, is it a bug? 2020-07-06 12:22 ` Gregory Heytings via Emacs development discussions. @ 2020-07-06 16:41 ` Eli Zaretskii 2020-07-06 17:08 ` Gregory Heytings via Emacs development discussions. 0 siblings, 1 reply; 29+ messages in thread From: Eli Zaretskii @ 2020-07-06 16:41 UTC (permalink / raw) To: Gregory Heytings; +Cc: emacs-devel > Date: Mon, 6 Jul 2020 14:22:16 +0200 (CEST) > From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org> > > So it seems that it's only when a face remapping takes place that an > omitted face in [1] means using the default face. Before the face > remapping takes place, the fringe face is used instead. No, it uses the default face, but the result is produced slightly differently (not by actually merging the two faces). ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: buffer-face-set changes the fringe, is it a bug? 2020-07-06 16:41 ` Eli Zaretskii @ 2020-07-06 17:08 ` Gregory Heytings via Emacs development discussions. 2020-07-06 18:08 ` Eli Zaretskii 0 siblings, 1 reply; 29+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-07-06 17:08 UTC (permalink / raw) To: emacs-devel > >> So it seems that it's only when a face remapping takes place that an >> omitted face in [1] means using the default face. Before the face >> remapping takes place, the fringe face is used instead. > > No, it uses the default face, but the result is produced slightly > differently (not by actually merging the two faces). > Sorry, but that doesn't make any sense. The default face does not contain any blue or red, it's black on white. So how could blue or red enter into the face when no face is specified (i.e. when the face is omitted)? At the very least, this is not what one understands with the (previous or current) documentation. I'm not entirely sure, but apparently the logic in draw_fringe_bitmap_1() is to take DEFAULT_FACE_ID as an initial value for face_id, and if face_id is not set explicitly to a different value, to reset its value to FRINGE_FACE_ID. In handle_single_display_spec(), face_id is initially set to DEFAULT_FACE_ID, which means (given the above) that when face is omitted it is FRINGE_FACE_ID that will in fact be used. When face is 'fringe' the derived face that is created is equivalent to FRINGE_FACE_ID. When face is explicitly set to 'default', a derived face is created, and is subjected to face remappings in the buffer. I think again that this is a bug, and that one should have (if my understanding is correct), in handle_single_display_spec(): int face_id = lookup_fasic_Face (it->f, FRINGE_FACE_ID); instead of: int face_id = lookup_basic_face (it->f, DEFAULT_FACE_ID); Gregory ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: buffer-face-set changes the fringe, is it a bug? 2020-07-06 17:08 ` Gregory Heytings via Emacs development discussions. @ 2020-07-06 18:08 ` Eli Zaretskii 2020-07-06 18:55 ` Gregory Heytings via Emacs development discussions. 0 siblings, 1 reply; 29+ messages in thread From: Eli Zaretskii @ 2020-07-06 18:08 UTC (permalink / raw) To: Gregory Heytings; +Cc: emacs-devel > Date: Mon, 6 Jul 2020 19:08:39 +0200 (CEST) > From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org> > > > No, it uses the default face, but the result is produced slightly > > differently (not by actually merging the two faces). > > > > Sorry, but that doesn't make any sense. The default face does not contain > any blue or red, it's black on white. So how could blue or red enter into > the face when no face is specified (i.e. when the face is omitted)? At > the very least, this is not what one understands with the (previous or > current) documentation. You need to look at the code to make sense of what I said. > I'm not entirely sure, but apparently the logic in draw_fringe_bitmap_1() > is to take DEFAULT_FACE_ID as an initial value for face_id, and if face_id > is not set explicitly to a different value, to reset its value to > FRINGE_FACE_ID. > > In handle_single_display_spec(), face_id is initially set to > DEFAULT_FACE_ID, which means (given the above) that when face is omitted > it is FRINGE_FACE_ID that will in fact be used. When face is 'fringe' the > derived face that is created is equivalent to FRINGE_FACE_ID. When face > is explicitly set to 'default', a derived face is created, and is > subjected to face remappings in the buffer. Yes. > I think again that this is a bug, and that one should have (if my > understanding is correct), in handle_single_display_spec(): > > int face_id = lookup_fasic_Face (it->f, FRINGE_FACE_ID); > > instead of: > > int face_id = lookup_basic_face (it->f, DEFAULT_FACE_ID); I disagreed already, and provide my reasons. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: buffer-face-set changes the fringe, is it a bug? 2020-07-06 18:08 ` Eli Zaretskii @ 2020-07-06 18:55 ` Gregory Heytings via Emacs development discussions. 2020-07-07 12:59 ` Gregory Heytings via Emacs development discussions. 0 siblings, 1 reply; 29+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-07-06 18:55 UTC (permalink / raw) To: emacs-devel > >> Sorry, but that doesn't make any sense. The default face does not >> contain any blue or red, it's black on white. So how could blue or red >> enter into the face when no face is specified (i.e. when the face is >> omitted)? At the very least, this is not what one understands with the >> (previous or current) documentation. > > You need to look at the code to make sense of what I said. > ... and to make sense of what the documentation says. I think this is problematic. > >> I'm not entirely sure, but apparently the logic in >> draw_fringe_bitmap_1() is to take DEFAULT_FACE_ID as an initial value >> for face_id, and if face_id is not set explicitly to a different value, >> to reset its value to FRINGE_FACE_ID. >> >> In handle_single_display_spec(), face_id is initially set to >> DEFAULT_FACE_ID, which means (given the above) that when face is >> omitted it is FRINGE_FACE_ID that will in fact be used. When face is >> 'fringe' the derived face that is created is equivalent to >> FRINGE_FACE_ID. When face is explicitly set to 'default', a derived >> face is created, and is subjected to face remappings in the buffer. > > Yes. > So the documentation should be: The optional @var{face} names a face whose foreground and background colors are to be used to display the bitmap; this face is automatically merged with the @code{fringe} face. When @var{face} is omitted and the @code{default} face has not been remapped, that effectively means to use the @code{fringe} face. When @var{face} is omitted and the @code{default} face has been remapped, that means to use the remapped @code{default} face. It is not recommended to omit the @var{face}: it is recommended to indicate the @code{fringe} face when one does not want to use another face. Compare this with what one would naturally expect, and which is in fact very close to the previous version of the documentation: The optional @var{face} names a face whose foreground and background colors are to be used to display the bitmap; this face is automatically merged with the @code{fringe} face. When @var{face} is omitted, this means to use the @code{fringe} face. > >> I think again that this is a bug, and that one should have (if my >> understanding is correct), in handle_single_display_spec(): >> >> int face_id = lookup_basic_face (it->f, FRINGE_FACE_ID); >> >> instead of: >> >> int face_id = lookup_basic_face (it->f, DEFAULT_FACE_ID); > > I disagreed already, and provide my reasons. > Hmmm... I don't think they are convincing, and I do think that the current behavior is not what one would naturally expect. But I'm not in a position to impose anything. Thanks again for your attention. Gregory ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: buffer-face-set changes the fringe, is it a bug? 2020-07-06 18:55 ` Gregory Heytings via Emacs development discussions. @ 2020-07-07 12:59 ` Gregory Heytings via Emacs development discussions. 2020-07-07 14:59 ` Eli Zaretskii 0 siblings, 1 reply; 29+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-07-07 12:59 UTC (permalink / raw) To: emacs-devel A (last?) note on this. Fringes were introduced in Emacs 21, and face remappings much later, in Emacs 23. Before face remappings existed (i.e. in Emacs 21 and 22), a left/right-fringe display property with an omitted face meant using the fringe face without modifications. It is only when face remappings, a feature completely unrelated to fringe displays, were introduced, that the current behavior (to use the fringe face when the default face has not been remapped, and the remapped default face otherwise) started to exist. Gregory ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: buffer-face-set changes the fringe, is it a bug? 2020-07-07 12:59 ` Gregory Heytings via Emacs development discussions. @ 2020-07-07 14:59 ` Eli Zaretskii 2020-07-07 15:47 ` Gregory Heytings via Emacs development discussions. 0 siblings, 1 reply; 29+ messages in thread From: Eli Zaretskii @ 2020-07-07 14:59 UTC (permalink / raw) To: Gregory Heytings; +Cc: emacs-devel > Date: Tue, 7 Jul 2020 14:59:03 +0200 (CEST) > From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org> > > A (last?) note on this. Fringes were introduced in Emacs 21, and face > remappings much later, in Emacs 23. Before face remappings existed (i.e. > in Emacs 21 and 22), a left/right-fringe display property with an omitted > face meant using the fringe face without modifications. It is only when > face remappings, a feature completely unrelated to fringe displays, were > introduced, that the current behavior (to use the fringe face when the > default face has not been remapped, and the remapped default face > otherwise) started to exist. This is not what I see. The left/right-fringe display property (which was introduced in Emacs 22.1, btw) behaves in Emacs 22 exactly like it behaves in the current codebase: if the optional FACE parameter is omitted, it uses the foreground of the 'default' face and the background of the 'fringe' face (because the 'fringe' face by default doesn't specify the foreground). Try this: (set-face-attribute 'fringe nil :background "red") (let ((o (make-overlay 0 1)) (s "_")) (put-text-property 0 1 'display '(left-fringe question-mark) s) (overlay-put o 'after-string s) (set-face-foreground 'default "green")) and you will see that the foreground of the question-mark bitmap becomes green. IOW, Emacs in this case merges the 'fringe' and the 'default' faces, starting from 'default' (so any color specified by 'fringe' overrides the corresponding color of 'default'). By contrast, when you specify FACE, Emacs merges that face with 'fringe' starting from 'fringe'. This different order of merging is what causes the results which confused you; the implementation didn't change since it was introduced in Emacs 22.1. The relation with face remapping is subtle and almost tangential: face remapping doesn't modify the 'default' face, it creates a new face which select Emacs features use _instead_ of the original 'default'. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: buffer-face-set changes the fringe, is it a bug? 2020-07-07 14:59 ` Eli Zaretskii @ 2020-07-07 15:47 ` Gregory Heytings via Emacs development discussions. 2020-07-07 18:34 ` Eli Zaretskii 0 siblings, 1 reply; 29+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-07-07 15:47 UTC (permalink / raw) To: emacs-devel > > This is not what I see. The left/right-fringe display property (which > was introduced in Emacs 22.1, btw) behaves in Emacs 22 exactly like it > behaves in the current codebase: if the optional FACE parameter is > omitted, it uses the foreground of the 'default' face and the background > of the 'fringe' face (because the 'fringe' face by default doesn't > specify the foreground). Try this: > > (set-face-attribute 'fringe nil :background "red") > (let ((o (make-overlay 0 1)) (s "_")) > (put-text-property 0 1 'display '(left-fringe question-mark) s) > (overlay-put o 'after-string s) > (set-face-foreground 'default "green")) > Why did you change my code, which demonstrated the problem, into another one which indeed does not show the problem? Try this: (set-face-attribute 'fringe nil :background "red" :foreground "blue") (let ((o (make-overlay 0 1)) (s "_")) (put-text-property 0 1 'display '(left-fringe question-mark) s) (overlay-put o 'after-string s)) (progn (set-face-background 'default "yellow") (set-face-foreground 'default "red")) [1] (face-remap-add-relative 'default '(:background "yellow" :foreground "red")) [2] After [1] the behavior is what I expect: red on yellow in the buffer, blue on red in the fringe. After [2] the behavior is *not* what I expect anymore: red on yellow in the buffer, red on yellow for the question mark in the fringe (the other parts of the fringe remain red, and other bitmaps in the fringe, e.g. curly arrows, remain blue on a red background). Gregory ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: buffer-face-set changes the fringe, is it a bug? 2020-07-07 15:47 ` Gregory Heytings via Emacs development discussions. @ 2020-07-07 18:34 ` Eli Zaretskii 2020-07-07 18:47 ` Gregory Heytings via Emacs development discussions. 0 siblings, 1 reply; 29+ messages in thread From: Eli Zaretskii @ 2020-07-07 18:34 UTC (permalink / raw) To: Gregory Heytings; +Cc: emacs-devel > Date: Tue, 7 Jul 2020 17:47:55 +0200 (CEST) > From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org> > > > (set-face-attribute 'fringe nil :background "red") > > (let ((o (make-overlay 0 1)) (s "_")) > > (put-text-property 0 1 'display '(left-fringe question-mark) s) > > (overlay-put o 'after-string s) > > (set-face-foreground 'default "green")) > > > > Why did you change my code, which demonstrated the problem, into another > one which indeed does not show the problem? Because I tried to explain something, in the text that you removed. > Try this: > > (set-face-attribute 'fringe nil :background "red" :foreground "blue") > (let ((o (make-overlay 0 1)) (s "_")) > (put-text-property 0 1 'display '(left-fringe question-mark) s) > (overlay-put o 'after-string s)) > (progn (set-face-background 'default "yellow") (set-face-foreground 'default "red")) [1] > (face-remap-add-relative 'default '(:background "yellow" :foreground "red")) [2] > > After [1] the behavior is what I expect: red on yellow in the buffer, blue > on red in the fringe. Certainly: since in this example the 'fringe' face defines both the foreground and the background colors, none of the colors of the 'default' face show. > After [2] the behavior is *not* what I expect anymore: red on yellow in > the buffer, red on yellow for the question mark in the fringe (the other > parts of the fringe remain red, and other bitmaps in the fringe, e.g. > curly arrows, remain blue on a red background). Because now what you call 'default' is not the original 'default' face, it's a new face created by face-remapping machinery. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: buffer-face-set changes the fringe, is it a bug? 2020-07-07 18:34 ` Eli Zaretskii @ 2020-07-07 18:47 ` Gregory Heytings via Emacs development discussions. 2020-07-07 19:20 ` Eli Zaretskii 0 siblings, 1 reply; 29+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-07-07 18:47 UTC (permalink / raw) To: emacs-devel > > Because I tried to explain something, in the text that you removed. > I did read it, but it explains the opposite of what happens. >> Try this: >> >> (set-face-attribute 'fringe nil :background "red" :foreground "blue") >> (let ((o (make-overlay 0 1)) (s "_")) >> (put-text-property 0 1 'display '(left-fringe question-mark) s) >> (overlay-put o 'after-string s)) >> (progn (set-face-background 'default "yellow") (set-face-foreground 'default "red")) [1] >> (face-remap-add-relative 'default '(:background "yellow" :foreground "red")) [2] >> >> After [1] the behavior is what I expect: red on yellow in the buffer, >> blue on red in the fringe. > > Certainly: since in this example the 'fringe' face defines both the > foreground and the background colors, none of the colors of the > 'default' face show. > Indeed. So far so good. > >> After [2] the behavior is *not* what I expect anymore: red on yellow in >> the buffer, red on yellow for the question mark in the fringe (the >> other parts of the fringe remain red, and other bitmaps in the fringe, >> e.g. curly arrows, remain blue on a red background). > > Because now what you call 'default' is not the original 'default' face, > it's a new face created by face-remapping machinery. > Now what you wrote is: "Emacs in this case [with an omitted face] merges the 'fringe' and the 'default' faces, starting from 'default' (so any color specified by 'fringe' overrides the corresponding color of 'default')." So what should happen is that the colors specified by 'fringe' override the corresponding colors of 'default', which is not the case here. Whether this 'default' one is the original default face or a new 'default' face created by face remapping should not matter in this case. Gregory ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: buffer-face-set changes the fringe, is it a bug? 2020-07-07 18:47 ` Gregory Heytings via Emacs development discussions. @ 2020-07-07 19:20 ` Eli Zaretskii 2020-07-07 19:44 ` Gregory Heytings via Emacs development discussions. 0 siblings, 1 reply; 29+ messages in thread From: Eli Zaretskii @ 2020-07-07 19:20 UTC (permalink / raw) To: Gregory Heytings; +Cc: emacs-devel > Date: Tue, 7 Jul 2020 20:47:19 +0200 (CEST) > From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org> > > Whether this 'default' one is the original default face or a new > 'default' face created by face remapping should not matter in this > case. Well, it does. because face-remapping creates a new face. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: buffer-face-set changes the fringe, is it a bug? 2020-07-07 19:20 ` Eli Zaretskii @ 2020-07-07 19:44 ` Gregory Heytings via Emacs development discussions. 2020-07-08 2:24 ` Eli Zaretskii 0 siblings, 1 reply; 29+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-07-07 19:44 UTC (permalink / raw) To: emacs-devel > >> Whether this 'default' one is the original default face or a new >> 'default' face created by face remapping should not matter in this >> case. > > Well, it does. because face-remapping creates a new face. > And? I really don't get it. There are two cases: With an omitted face in a fringe display element, either: (1) "Emacs merges the 'fringe' and the 'default' faces, starting from 'default' (so any color specified by 'fringe' overrides the corresponding color of 'default')." or: (2) When the 'default' face is remapped, Emacs completely ignores the 'fringe' face, and uses the remapped 'default' face instead. Gregory ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: buffer-face-set changes the fringe, is it a bug? 2020-07-07 19:44 ` Gregory Heytings via Emacs development discussions. @ 2020-07-08 2:24 ` Eli Zaretskii 2020-07-08 6:55 ` Gregory Heytings via Emacs development discussions. 0 siblings, 1 reply; 29+ messages in thread From: Eli Zaretskii @ 2020-07-08 2:24 UTC (permalink / raw) To: Gregory Heytings; +Cc: emacs-devel > Date: Tue, 7 Jul 2020 21:44:43 +0200 (CEST) > From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org> > > (2) When the 'default' face is remapped, Emacs completely ignores the > 'fringe' face, and uses the remapped 'default' face instead. It doesn't "ignore", but because the remapped face specifies both colors, the fringe colors don't show. That's what happens when you merge two faces one of which specifies both colors: if the face that specifies both colors is merged last, the colors of the first one will not show. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: buffer-face-set changes the fringe, is it a bug? 2020-07-08 2:24 ` Eli Zaretskii @ 2020-07-08 6:55 ` Gregory Heytings via Emacs development discussions. 2020-07-08 7:00 ` Gregory Heytings via Emacs development discussions. 0 siblings, 1 reply; 29+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-07-08 6:55 UTC (permalink / raw) To: emacs-devel > >> (2) When the 'default' face is remapped, Emacs completely ignores the >> 'fringe' face, and uses the remapped 'default' face instead. > > It doesn't "ignore", but because the remapped face specifies both > colors, the fringe colors don't show. That's what happens when you > merge two faces one of which specifies both colors: if the face that > specifies both colors is merged last, the colors of the first one will > not show. > And the question is precisely: why is the default face merged LAST in this case when, according to the documentation and to what you wrote, it should be merged FIRST? IOW, there are two cases: (1) "Emacs merges the 'fringe' and the 'default' faces, starting from 'default' (so any color specified by 'fringe' overrides the corresponding color of 'default')." (2) When the 'default' face is remapped, Emacs merges the 'fringe' and the 'default' faces, starting from 'fringe' (which effictively means that, given that 'default' always specifies a foreground and a background, any color specified by 'fringe' will be overridden). Four more examples: (a) This works even if the remapping of the default face does not change the color specified for the fringe face. Try this: (set-face-attribute 'fringe nil :foreground "red") (let ((o (make-overlay 0 1)) (s "_")) (put-text-property 0 1 'display '(left-fringe question-mark) s) (overlay-put o 'after-string s)) (face-remap-add-relative 'default '(:background "yellow")) (b) This works even if the remapping of the default face does not change the colors at all. Try this: (set-face-attribute 'fringe nil :background "red" :foreground "yellow") (let ((o (make-overlay 0 1)) (s "_")) (put-text-property 0 1 'display '(left-fringe question-mark) s) (overlay-put o 'after-string s)) (face-remap-add-relative 'default '(:weight bold)) (c) This works even if the remapping of the default face does not change anything visually. Try this: (set-face-attribute 'fringe nil :background "red" :foreground "yellow") (let ((o (make-overlay 0 1)) (s "_")) (put-text-property 0 1 'display '(left-fringe question-mark) s) (overlay-put o 'after-string s)) (face-remap-add-relative 'default `(:weight ,(face-attribute 'default :weight))) (d) This works also when one simply adjust the text scale with C-x C-- and C-x C-+: (set-face-attribute 'fringe nil :background "red" :foreground "yellow") (let ((o (make-overlay 0 1)) (s "_")) (put-text-property 0 1 'display '(left-fringe question-mark) s) (overlay-put o 'after-string s)) (text-scale-adjust -1) (text-scale-adjust +1) After C-x C-- the question mark is black on white, after C-x C-+ the question mark is yellow on red again. I start arguing now. Apparently this behavior is old enough that it is now, by definition, a feature. Moreover I'm the only one who took part of this thread, so it is perhaps not important. But please adjust the documentation (I've just seen that you updated it twice already) as follows: The optional @var{face} names a face whose foreground and background colors are to be used to display the bitmap, using the attributes of the @code{fringe} face for colors that @var{face} didn't specify. It is not recommended to omit the @var{face}, and to explicitly indicate the @code{fringe} face when one does not want to use specific colors to display the bitmap in the fringe, as an omitted @var{face} leads to unexpected behavior. If @var{face} is omitted and the @code{default} face is not remapped, that means to use the attributes of the @code{default} face for the colors which the @code{fringe} face didn't specify. If @var{face} is omitted and the @code{default} face is remapped, that means to use the attributes of the @code{fringe} face for the colors which the @code{default} face didn't specify. Thank you (once again) for your attention. Gregory ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: buffer-face-set changes the fringe, is it a bug? 2020-07-08 6:55 ` Gregory Heytings via Emacs development discussions. @ 2020-07-08 7:00 ` Gregory Heytings via Emacs development discussions. 2020-07-08 14:41 ` Eli Zaretskii 0 siblings, 1 reply; 29+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-07-08 7:00 UTC (permalink / raw) To: emacs-devel A small improvement to my suggested documentation: The optional @var{face} names a face whose foreground and background colors are to be used to display the bitmap, using the attributes of the @code{fringe} face for colors that @var{face} didn't specify. It is not recommended to omit the @var{face}, as an omitted @var{face} leads to unexpected behavior. It is recommended to explicitly indicate the @code{fringe} face when one does not want to use specific colors to display the bitmap in the fringe. If @var{face} is omitted and the @code{default} face is not remapped, that means to use the attributes of the @code{default} face for the colors which the @code{fringe} face didn't specify. If @var{face} is omitted and the @code{default} face is remapped, that means to use the attributes of the @code{fringe} face for the colors which the @code{default} face didn't specify. Gregory ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: buffer-face-set changes the fringe, is it a bug? 2020-07-08 7:00 ` Gregory Heytings via Emacs development discussions. @ 2020-07-08 14:41 ` Eli Zaretskii 2020-07-09 3:01 ` Richard Stallman 0 siblings, 1 reply; 29+ messages in thread From: Eli Zaretskii @ 2020-07-08 14:41 UTC (permalink / raw) To: Gregory Heytings; +Cc: emacs-devel > Date: Wed, 8 Jul 2020 09:00:12 +0200 (CEST) > From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org> > > > A small improvement to my suggested documentation: > > The optional @var{face} names a face whose foreground and background > colors are to be used to display the bitmap, using the attributes of the > @code{fringe} face for colors that @var{face} didn't specify. It is not > recommended to omit the @var{face}, as an omitted @var{face} leads to > unexpected behavior. It is recommended to explicitly indicate the > @code{fringe} face when one does not want to use specific colors to > display the bitmap in the fringe. If @var{face} is omitted and the > @code{default} face is not remapped, that means to use the attributes of > the @code{default} face for the colors which the @code{fringe} face didn't > specify. If @var{face} is omitted and the @code{default} face is > remapped, that means to use the attributes of the @code{fringe} face for > the colors which the @code{default} face didn't specify. It is not useful to say in the manual that something produces unexpected results. So I installed a slightly different description of this subtlety. Thanks. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: buffer-face-set changes the fringe, is it a bug? 2020-07-08 14:41 ` Eli Zaretskii @ 2020-07-09 3:01 ` Richard Stallman 2020-07-09 7:01 ` Gregory Heytings via Emacs development discussions. 2020-07-09 17:14 ` Eli Zaretskii 0 siblings, 2 replies; 29+ messages in thread From: Richard Stallman @ 2020-07-09 3:01 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ghe, emacs-devel [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > It is not useful to say in the manual that something produces > unexpected results. Yes, it is better to be a little more specific than that. > It is not > > recommended to omit the @var{face}, as an omitted @var{face} leads to > > unexpected behavior. Why not make that an error instead? -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: buffer-face-set changes the fringe, is it a bug? 2020-07-09 3:01 ` Richard Stallman @ 2020-07-09 7:01 ` Gregory Heytings via Emacs development discussions. 2020-07-09 17:17 ` Eli Zaretskii 2020-07-09 17:14 ` Eli Zaretskii 1 sibling, 1 reply; 29+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-07-09 7:01 UTC (permalink / raw) To: emacs-devel > > > > It is not recommended to omit the @var{face}, as an omitted > > > @var{face} leads to unexpected behavior. > > Why not make that an error instead? > Another possibility, which I didn't think about earlier, would be to (implicitly) use an empty face, that is, to make omitting the face equivalent to specifying an empty face in xdisp.c:handle_single_display_spec(). This works perfectly well: (defface empty-face '((t nil)) "") (set-face-attribute 'fringe nil :background "red" :foreground "yellow") (overlay-put (make-overlay (point) (point)) 'before-string (propertize "_" 'display `(left-fringe question-mark empty-face))) (text-scale-adjust -1) (text-scale-adjust +1) Gregory ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: buffer-face-set changes the fringe, is it a bug? 2020-07-09 7:01 ` Gregory Heytings via Emacs development discussions. @ 2020-07-09 17:17 ` Eli Zaretskii 0 siblings, 0 replies; 29+ messages in thread From: Eli Zaretskii @ 2020-07-09 17:17 UTC (permalink / raw) To: Gregory Heytings; +Cc: emacs-devel > Date: Thu, 9 Jul 2020 09:01:16 +0200 (CEST) > From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org> > > Another possibility, which I didn't think about earlier, would be to > (implicitly) use an empty face, that is, to make omitting the face > equivalent to specifying an empty face in > xdisp.c:handle_single_display_spec(). This works perfectly well: There's no reason to change anything in xdisp.c because you can have what you want without any changes. It is unwise to change long-standing behavior because in some situations it could produce results that might surprise some people. And now that we have the documentation more elaborate on this, that confusion should be even more rare. It's time we've put this minor issue to rest. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: buffer-face-set changes the fringe, is it a bug? 2020-07-09 3:01 ` Richard Stallman 2020-07-09 7:01 ` Gregory Heytings via Emacs development discussions. @ 2020-07-09 17:14 ` Eli Zaretskii 2020-07-10 10:24 ` Gregory Heytings via Emacs development discussions. 1 sibling, 1 reply; 29+ messages in thread From: Eli Zaretskii @ 2020-07-09 17:14 UTC (permalink / raw) To: rms; +Cc: ghe, emacs-devel > From: Richard Stallman <rms@gnu.org> > Cc: ghe@sdf.org, emacs-devel@gnu.org > Date: Wed, 08 Jul 2020 23:01:25 -0400 > > > It is not > > > recommended to omit the @var{face}, as an omitted @var{face} leads to > > > unexpected behavior. > > Why not make that an error instead? Because it is not an error, it's an entirely valid usage. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: buffer-face-set changes the fringe, is it a bug? 2020-07-09 17:14 ` Eli Zaretskii @ 2020-07-10 10:24 ` Gregory Heytings via Emacs development discussions. 0 siblings, 0 replies; 29+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-07-10 10:24 UTC (permalink / raw) To: Eli Zaretskii, rms; +Cc: emacs-devel > >> Why not make that an error instead? > > Because it is not an error, it's an entirely valid usage. > That you do not want to change the code is xdisp.c is one thing, with which I'm ok. That you claim that it's a "entirely valid usage" or a "minor issue" is another, and it is plain wrong. I cannot imagine a single scenario where what someone positively wants is to have the colors of an element in the fringe change when, for example, the text is scaled up and down. If you have such a case in mind, please provide it. I filed a bug report against diff-mode.el, in which this happens. What is true is that the default colors of the fringe (black on light gray) and the default colors of the buffer (black on white) are close enough that many users do not see the difference when this happens. I happen to use a different color for the fringe, and I'd bet I'm not the only one to do this. Note the explanation in NEWS.22, when this display property was introduced: "Format is `display (left-fringe BITMAP [FACE])', where BITMAP is a symbol identifying a fringe bitmap, either built-in or defined with `define-fringe-bitmap', and FACE is an optional face name to be used for displaying the bitmap ***instead of the default `fringe' face***. When specified, FACE is automatically merged with the `fringe' face." I took the liberty to add one more message to this already too long thread, to answer RMS's question. Now I stop arguing again. Thank you for your attention. Gregory ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2020-07-10 10:24 UTC | newest] Thread overview: 29+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-07-05 8:56 buffer-face-set changes the fringe, is it a bug? Gregory Heytings via Emacs development discussions. 2020-07-05 10:50 ` Eli Zaretskii 2020-07-05 12:43 ` Gregory Heytings via Emacs development discussions. 2020-07-05 15:32 ` Eli Zaretskii 2020-07-05 16:25 ` Gregory Heytings via Emacs development discussions. 2020-07-05 16:40 ` Eli Zaretskii 2020-07-05 16:59 ` Gregory Heytings via Emacs development discussions. 2020-07-05 17:24 ` Eli Zaretskii 2020-07-06 12:22 ` Gregory Heytings via Emacs development discussions. 2020-07-06 16:41 ` Eli Zaretskii 2020-07-06 17:08 ` Gregory Heytings via Emacs development discussions. 2020-07-06 18:08 ` Eli Zaretskii 2020-07-06 18:55 ` Gregory Heytings via Emacs development discussions. 2020-07-07 12:59 ` Gregory Heytings via Emacs development discussions. 2020-07-07 14:59 ` Eli Zaretskii 2020-07-07 15:47 ` Gregory Heytings via Emacs development discussions. 2020-07-07 18:34 ` Eli Zaretskii 2020-07-07 18:47 ` Gregory Heytings via Emacs development discussions. 2020-07-07 19:20 ` Eli Zaretskii 2020-07-07 19:44 ` Gregory Heytings via Emacs development discussions. 2020-07-08 2:24 ` Eli Zaretskii 2020-07-08 6:55 ` Gregory Heytings via Emacs development discussions. 2020-07-08 7:00 ` Gregory Heytings via Emacs development discussions. 2020-07-08 14:41 ` Eli Zaretskii 2020-07-09 3:01 ` Richard Stallman 2020-07-09 7:01 ` Gregory Heytings via Emacs development discussions. 2020-07-09 17:17 ` Eli Zaretskii 2020-07-09 17:14 ` Eli Zaretskii 2020-07-10 10:24 ` Gregory Heytings via Emacs development discussions.
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.