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