* bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face [not found] ` <<838s9jkqh7.fsf@gnu.org> @ 2020-12-27 19:56 ` Drew Adams 2020-12-28 13:43 ` Eli Zaretskii 0 siblings, 1 reply; 25+ messages in thread From: Drew Adams @ 2020-12-27 19:56 UTC (permalink / raw) To: Eli Zaretskii, Drew Adams; +Cc: larsi, stefan, triska, 45428 > > > You should indeed rely on documented behavior. But that doesn't mean > > > Emacs cannot have undocumented behavior, especially when it is a side > > > effect of the specific implementation of some documented feature. > > > > Agreed. But what is the specific need for this > > particular undocumented behavior? > > Who said there's a need? AFAIU, it's just an implementation artifact. What do you mean by that? Isn't everything that's implemented an implementation artifact, including bugs? Do we have any idea why this odd behavior was implemented? Or are you suggesting that the behavior was an accident? Is that what you meant by "artifact" here? If so, what would be the argument for not fixing it, if it was never intended in the first place and it flies in the face of Lisp's general behavior? ^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face 2020-12-27 19:56 ` bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face Drew Adams @ 2020-12-28 13:43 ` Eli Zaretskii 0 siblings, 0 replies; 25+ messages in thread From: Eli Zaretskii @ 2020-12-28 13:43 UTC (permalink / raw) To: Drew Adams; +Cc: larsi, stefan, triska, 45428 > Date: Sun, 27 Dec 2020 11:56:39 -0800 (PST) > From: Drew Adams <drew.adams@oracle.com> > Cc: triska@metalevel.at, drew.adams@oracle.com, larsi@gnus.org, > stefan@marxist.se, 45428@debbugs.gnu.org > > Or are you suggesting that the behavior was an accident? Yes! > what would be the argument for not fixing it That no one submitted a patch to reimplement that code in a way that won't allow such constructs. ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <<<<<<m2tusa3vzm.fsf@metalevel.at>]
[parent not found: <<<<<<87eejc9pnm.fsf@gnus.org>]
[parent not found: <<<<<<CADwFkm=Q9P-a+PJdiQzGWU9PkV1BhTEw9V4GPcFRAnuaFiUNVg@mail.gmail.com>]
[parent not found: <<<<<<5e99c39b-b67b-4184-a890-2cae38fb40de@default>]
[parent not found: <<<<<<87a6tzk5iv.fsf@metalevel.at>]
[parent not found: <<<<<<83h7o7kufk.fsf@gnu.org>]
[parent not found: <<<<<975c150b-99aa-4143-b057-8b5ec7caec19@default>]
[parent not found: <<<<<838s9jkqh7.fsf@gnu.org>]
[parent not found: <<<<fc9aea86-b07a-4f81-a442-019f610bb73a@default>]
[parent not found: <<<<835z4mkpvz.fsf@gnu.org>]
[parent not found: <<<5dfff982-e496-46fe-9efd-1e0edd4f0be8@default>]
[parent not found: <<<83o8idkehc.fsf@gnu.org>]
[parent not found: <<<83mtxxkcwk.fsf@gnu.org>]
[parent not found: <<9a600718-7caf-4ad0-a664-0ebafba63e57@default>]
[parent not found: <<83im8lk9lp.fsf@gnu.org>]
* bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face [not found] ` <<83im8lk9lp.fsf@gnu.org> @ 2020-12-28 20:44 ` Drew Adams 2020-12-29 14:53 ` Eli Zaretskii 0 siblings, 1 reply; 25+ messages in thread From: Drew Adams @ 2020-12-28 20:44 UTC (permalink / raw) To: Eli Zaretskii, Drew Adams; +Cc: larsi, stefan, triska, 45428 > > I see the same thing that I see when I use this: > > (insert (propertize "hello" 'face '(:height 10.0))) > > Not exactly the same, see below. > > > The bug, IMO, is that this is not "a sequence of > > PROPERY VALUE pairs...", which is what the doc > > says it should be: (quote (quote '(:height 10.0))) > > Right, it's not. > > > I wouldn't think of this as a doc bug because (1) > > this behavior is so unusual > > Which behavior are you alluding to here? and what is the "doc bug", > exactly? I was alluding to the fact that the doc says that "Remaining arguments form a sequence of PROPERTY VALUE pairs", but the inserted text seems to show the effect of the pair `face (:height 10.0)', even though that pair isn't present. Instead, the only pair is, in effect (by evaling the outermost `quote'), `face (quote '(:height 10.0))'. The value `(quote '(:height 10.0))' for text property `face' is different from the value `(:height 10.0)', but the effect seems to be the same. Likewise, if you use (quote (quote (quote (quote '(:height 10.0))))) > > Wrt #1: nowhere else, AFAIK, do we accept > > (quote (quote (quote SEXP))) > > or (quote (quote (quote (quote (quote SEXP))))) > > or <add more `quote' ...> as a substitute for SEXP. > > We don't "accept" it here, either. > > > We don't do that anywhere else, and I don't see > > why we should do it here (or anywhere)? > > We don't. Please look in *Messages*, and you will see that. OK. I see that if I click move point around in *Messages*, and with repetitions presumably from redisplay cycles, this is shown in *Messages*: Invalid face reference: quote There's no doubt some explanation for why the pair formed by nested `quote's doesn't just get rejected but is reported as invalid and has the innermost `(:height 10.0)' taken into account. No doubt you'll explain that (please), but at least I hope you can see that it's not obvious. Given an explanation, there's presumably no bug. So far, without an explanation, I don't understand the behavior. It's surprising, at the least. But I guess it has something to do with what's allowed as a face "reference" and how such are handled? If this is entirely normal behavior then I don't, off-hand, see a way to lessen the surprise by changing the doc. Do you? Depending on the explanation, maybe there's something that could or should be added to the manual about the behavior of anonymous face representations? Having heard the misunderstanding that we've made (still without my understanding, so far), do you have a suggestion for how to dispel/prevent it? ^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face 2020-12-28 20:44 ` Drew Adams @ 2020-12-29 14:53 ` Eli Zaretskii 2020-12-29 16:40 ` Markus Triska 2020-12-29 18:27 ` Drew Adams 0 siblings, 2 replies; 25+ messages in thread From: Eli Zaretskii @ 2020-12-29 14:53 UTC (permalink / raw) To: Drew Adams; +Cc: larsi, stefan, triska, 45428 > Date: Mon, 28 Dec 2020 12:44:11 -0800 (PST) > From: Drew Adams <drew.adams@oracle.com> > Cc: larsi@gnus.org, stefan@marxist.se, triska@metalevel.at, > 45428@debbugs.gnu.org > > > > I wouldn't think of this as a doc bug because (1) > > > this behavior is so unusual > > > > Which behavior are you alluding to here? and what is the "doc bug", > > exactly? > > I was alluding to the fact that the doc says that > "Remaining arguments form a sequence of PROPERTY > VALUE pairs", but the inserted text seems to show > the effect of the pair `face (:height 10.0)', even > though that pair isn't present. You are still not saying where did you find the documentation which says that. I will go ahead and guess that you mean the doc string of 'propertize', which says: First argument is the string to copy. Remaining arguments form a sequence of PROPERTY VALUE pairs for text properties to add to the result. If that is the documentation you are complaining about, then I find nothing wrong with, because the original recipe, viz.: (propertize "hello" 'face (quote (quote '(:height 10.0)))) does indeed call 'propertize' with a pair, as documented: the PROPERTY is 'face and the VALUE is (quote (quote '(:height 10.0))). So the doc string describes this use case accurately, and there's nothing wrong with the _form_ of the PROPERTIES arguments to 'propertize' in this case. The original bug report said something different: > In 39.12 Faces, the Emacs Lisp documentation states: > > One way to represent a face is as a property list of attributes, > like ‘(:foreground "red" :weight bold)’. Such a list is called an > “anonymous face”. [...] > $ emacs -Q --eval '(font-lock-mode 0)' \ > --eval "(insert (propertize \ > \"hello\" \ > 'face (quote (quote '(:height 10.0)))))" > > In this case, the anonymous face is not specified as a property list, > but as a symbolic expression of the form (quote (quote (quote ...))), > and still works. Is this the intended result, and can we rely on it? If > so, could you please document it? This complaint is about a different instance of "pairs": it's about the form of the _value_ of the 'face' property, not about the form of the "&rest PROPERTIES" arguments of 'propertize'. However, that original complaint is incorrectly assuming that a face can _only_ have the form of an anonymous face, which is a property list of attribute/value pairs. The text it quotes from section 39.12 of the ELisp manual is incomplete; here it is in its entirety: One way to represent a face is as a property list of attributes, like ‘(:foreground "red" :weight bold)’. Such a list is called an "anonymous face". For example, you can assign an anonymous face as the value of the ‘face’ text property, and Emacs will display the underlying text with the specified attributes. *Note Special Properties::. If you follow the cross-reference to "Special Properties", you will find that the value of the 'face' property can be one of the following: . a face symbol . a property list of attribute/value pairs . a cons cell of the form (foreground-color . COLOR) . a cons cell of the form (background-color . COLOR) . a list of faces, each one given by any of the above forms . a cons cell of the form (:filtered FILTER FACE-SPEC), where FACE-SPEC is one of the above forms And now you should recognize that the strange format of the property value, which prompted the original bug report, fits the "list of faces" format as described by the 5th item in the above list. So I still don't see a problem with the documentation in this case. I think the only problem/surprise here could be that Emacs acted according to a single valid part of the face spec and seemingly silently ignored the invalid ones, logging an error message in *Messages* instead of perhaps rejecting it wholesale, and the OP failed to look in *Messages*. However, that doesn't seem to be a bug: the face spec is invalid, and so invokes undefined behavior, where we only have an obligation not to crash nor lock up Emacs (which is why the error message isn't displayed as such: the face merging happens at display time, and we cannot usefully signal an error from redisplay). > Having heard the misunderstanding that we've made > (still without my understanding, so far), do you > have a suggestion for how to dispel/prevent it? Tell users to read the docs? But we already know that doesn't really work... ^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face 2020-12-29 14:53 ` Eli Zaretskii @ 2020-12-29 16:40 ` Markus Triska 2020-12-29 17:17 ` Eli Zaretskii 2020-12-29 18:27 ` Drew Adams 1 sibling, 1 reply; 25+ messages in thread From: Markus Triska @ 2020-12-29 16:40 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi, stefan, 45428 Eli Zaretskii <eliz@gnu.org> writes: > If you follow the cross-reference to "Special Properties", you will > find that the value of the 'face' property can be one of the > following: > > . a face symbol > . a property list of attribute/value pairs > . a cons cell of the form (foreground-color . COLOR) > . a cons cell of the form (background-color . COLOR) > . a list of faces, each one given by any of the above forms > . a cons cell of the form (:filtered FILTER FACE-SPEC), where > FACE-SPEC is one of the above forms > > And now you should recognize that the strange format of the property > value, which prompted the original bug report, fits the "list of > faces" format as described by the 5th item in the above list. In the original bug report, the property value has the form: (quote (quote (quote ...))) I recognize that it is a list. However, I do not recognize that each of its elements is given "by any of the above forms", i.e., by any of: > . a face symbol > . a property list of attribute/value pairs > . a cons cell of the form (foreground-color . COLOR) > . a cons cell of the form (background-color . COLOR) Could you please clarify which of these forms match (quote (quote ...)) ? Thank you a lot! Markus ^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face 2020-12-29 16:40 ` Markus Triska @ 2020-12-29 17:17 ` Eli Zaretskii 2020-12-29 18:39 ` Markus Triska 0 siblings, 1 reply; 25+ messages in thread From: Eli Zaretskii @ 2020-12-29 17:17 UTC (permalink / raw) To: Markus Triska; +Cc: larsi, stefan, 45428 > From: Markus Triska <triska@metalevel.at> > Cc: Drew Adams <drew.adams@oracle.com>, larsi@gnus.org, stefan@marxist.se, 45428@debbugs.gnu.org > Date: Tue, 29 Dec 2020 17:40:38 +0100 > > In the original bug report, the property value has the form: > > (quote (quote (quote ...))) > > I recognize that it is a list. However, I do not recognize that each of > its elements is given "by any of the above forms", i.e., by any of: > > > . a face symbol > > . a property list of attribute/value pairs > > . a cons cell of the form (foreground-color . COLOR) > > . a cons cell of the form (background-color . COLOR) > > Could you please clarify which of these forms match (quote (quote ...)) ? It's a list, obviously. And the face specification as a list can be recursive, because it can be a list of any mix of any of the allowed forms, including a list. ^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face 2020-12-29 17:17 ` Eli Zaretskii @ 2020-12-29 18:39 ` Markus Triska 2020-12-29 19:41 ` Eli Zaretskii 0 siblings, 1 reply; 25+ messages in thread From: Markus Triska @ 2020-12-29 18:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi, stefan, 45428 Eli Zaretskii <eliz@gnu.org> writes: >> I recognize that it is a list. However, I do not recognize that each of >> its elements is given "by any of the above forms", i.e., by any of: >> >> > . a face symbol >> > . a property list of attribute/value pairs >> > . a cons cell of the form (foreground-color . COLOR) >> > . a cons cell of the form (background-color . COLOR) >> >> Could you please clarify which of these forms match (quote (quote ...)) ? > > It's a list, obviously. And the face specification as a list can be > recursive, because it can be a list of any mix of any of the allowed > forms, including a list. That's different from the documentation you quoted, which said "by any of the above forms", not "by any of the allowed forms". If it is any mix of any of the allowed forms, could you please consider stating that in the documentation? Thank you, Markus ^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face 2020-12-29 18:39 ` Markus Triska @ 2020-12-29 19:41 ` Eli Zaretskii 0 siblings, 0 replies; 25+ messages in thread From: Eli Zaretskii @ 2020-12-29 19:41 UTC (permalink / raw) To: Markus Triska; +Cc: larsi, stefan, 45428 > From: Markus Triska <triska@metalevel.at> > Cc: drew.adams@oracle.com, larsi@gnus.org, stefan@marxist.se, 45428@debbugs.gnu.org > Date: Tue, 29 Dec 2020 19:39:48 +0100 > > > It's a list, obviously. And the face specification as a list can be > > recursive, because it can be a list of any mix of any of the allowed > > forms, including a list. > > That's different from the documentation you quoted, which said "by any > of the above forms", not "by any of the allowed forms". No, it says "a list of faces". > If it is any mix of any of the allowed forms, could you please consider > stating that in the documentation? I see no need, sorry. ^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face 2020-12-29 14:53 ` Eli Zaretskii 2020-12-29 16:40 ` Markus Triska @ 2020-12-29 18:27 ` Drew Adams 2020-12-29 19:39 ` Eli Zaretskii 1 sibling, 1 reply; 25+ messages in thread From: Drew Adams @ 2020-12-29 18:27 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi, stefan, triska, 45428 > The original bug report said something different:... > However, that original complaint is incorrectly assuming that a face > can _only_ have the form of an anonymous face, which is a property > list of attribute/value pairs. The text it quotes from section 39.12 > of the ELisp manual is incomplete; here it is in its entirety: > > One way to represent a face is as a property list of attributes, like > ‘(:foreground "red" :weight bold)’. Such a list is called an "anonymous > face". For example, you can assign an anonymous face as the value of > the ‘face’ text property, and Emacs will display the underlying text > with the specified attributes. *Note Special Properties::. I think it would help if that simple "See Special Properties" were called out explicitly as telling you to see that node for a complete description of the `face' property. The text before it and after it can indeed give a false impression about property `face' and how a face can be represented. > If you follow the cross-reference to "Special Properties", you will > find that the value of the 'face' property can be one of the > following: > > . a face symbol > . a property list of attribute/value pairs > . a cons cell of the form (foreground-color . COLOR) > . a cons cell of the form (background-color . COLOR) > . a list of faces, each one given by any of the above forms > . a cons cell of the form (:filtered FILTER FACE-SPEC), where > FACE-SPEC is one of the above forms > > And now you should recognize that the strange format of the property > value, which prompted the original bug report, fits the "list of > faces" format as described by the 5th item in the above list. Indeed. I thought that's what you might say. Yes, that description is fine. But I hope you'll recognize that the (quote (quote '(...))) example is a gotcha, especially given that the "Invalid face reference: quote" message is shown in *Messages* only after some action provokes redisplay, and it often is not seen in the echo area. Without your having piped up here to say "Please look in *Messages*" I wouldn't have noticed it, for example. If this were a court of law, your argument that the doc is fine would be convincing. But if we're trying to help and guide users, then I think this `quote' gotcha could be handled better. Better still perhaps, instead of trying to address the specific `quote' gotcha (which is particularly misleading), the "Invalid face..." interaction could perhaps be improved. If that msg were (1) more visible and immediate and (2) said more about what is invalid (even just pointing out that here `quote' is taken as a face name or whatever), that might help. > So I still don't see a problem with the documentation in this case. See above. We could maybe help users a bit more, without giving up any of the exactness of the spec given in `Special Properties' etc. > I think the only problem/surprise here could be that Emacs acted > according to a single valid part of the face spec and seemingly > silently ignored the invalid ones, logging an error message in > *Messages* instead of perhaps rejecting it wholesale, and the OP > failed to look in *Messages*. Yes, now we're thinking along the same lines. The real problem is the interaction with the user and the inadequacy of the message, IMO. > However, that doesn't seem to be a bug: > the face spec is invalid, Yes, but can we say why, in what way, what about it is invalid? (If the doc in question actually referred to "face spec" instead of "face" or "face representation", that would be a start. It would guide user toward the part of the doc that says what can be in a face spec.) > and so invokes undefined behavior, where we > only have an obligation not to crash nor lock up Emacs (which is why > the error message isn't displayed as such: the face merging happens at > display time, and we cannot usefully signal an error from redisplay). I was afraid you might say that. All I can say is that if we can possibly do something better that would help. There are gotchas in Emacs that we can't really prevent or guide users away from (e.g. using existing names of things in perverted, misleading ways). I was hoping this is one where we might be able to help a bit. > > Having heard the misunderstanding that we've made > > (still without my understanding, so far), do you > > have a suggestion for how to dispel/prevent it? > > Tell users to read the docs? But we already know > that doesn't really work... In this case, the problem (IMO) is that the doc they are led to doesn't guide them to the doc that really helps with this. See above. ^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face 2020-12-29 18:27 ` Drew Adams @ 2020-12-29 19:39 ` Eli Zaretskii 2020-12-30 2:54 ` Lars Ingebrigtsen 0 siblings, 1 reply; 25+ messages in thread From: Eli Zaretskii @ 2020-12-29 19:39 UTC (permalink / raw) To: Drew Adams; +Cc: larsi, stefan, triska, 45428 > Date: Tue, 29 Dec 2020 10:27:11 -0800 (PST) > From: Drew Adams <drew.adams@oracle.com> > Cc: larsi@gnus.org, stefan@marxist.se, triska@metalevel.at, > 45428@debbugs.gnu.org > > Indeed. I thought that's what you might say. Yes, > that description is fine. But I hope you'll recognize > that the (quote (quote '(...))) example is a gotcha, > especially given that the "Invalid face reference: > quote" message is shown in *Messages* only after some > action provokes redisplay, and it often is not seen > in the echo area. Without your having piped up here > to say "Please look in *Messages*" I wouldn't have > noticed it, for example. We cannot signal an error from redisplay, so all we can do is log the error in *Messages*. We do that with any error inside redisplay, there's nothing new here. > Better still perhaps, instead of trying to address > the specific `quote' gotcha (which is particularly > misleading), the "Invalid face..." interaction could > perhaps be improved. If that msg were (1) more > visible and immediate and (2) said more about what > is invalid (even just pointing out that here `quote' > is taken as a face name or whatever), that might help. Patches to make the diagnostics in this case are welcome. The code that implements the face merging and deals with these forms is quite simple, and doesn't really know what's wrong with the face in this case, it just knows it's invalid. ^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face 2020-12-29 19:39 ` Eli Zaretskii @ 2020-12-30 2:54 ` Lars Ingebrigtsen 0 siblings, 0 replies; 25+ messages in thread From: Lars Ingebrigtsen @ 2020-12-30 2:54 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 45428, stefan, triska Eli Zaretskii <eliz@gnu.org> writes: > We cannot signal an error from redisplay, so all we can do is log the > error in *Messages*. We do that with any error inside redisplay, > there's nothing new here. I think that's the conclusion here, and I'm closing this bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <<<<<m2tusa3vzm.fsf@metalevel.at>]
[parent not found: <<<<<87eejc9pnm.fsf@gnus.org>]
[parent not found: <<<<<CADwFkm=Q9P-a+PJdiQzGWU9PkV1BhTEw9V4GPcFRAnuaFiUNVg@mail.gmail.com>]
[parent not found: <<<<<5e99c39b-b67b-4184-a890-2cae38fb40de@default>]
[parent not found: <<<<<87a6tzk5iv.fsf@metalevel.at>]
[parent not found: <<<<<83h7o7kufk.fsf@gnu.org>]
[parent not found: <<<<975c150b-99aa-4143-b057-8b5ec7caec19@default>]
[parent not found: <<<<838s9jkqh7.fsf@gnu.org>]
[parent not found: <<<fc9aea86-b07a-4f81-a442-019f610bb73a@default>]
[parent not found: <<<835z4mkpvz.fsf@gnu.org>]
[parent not found: <<5dfff982-e496-46fe-9efd-1e0edd4f0be8@default>]
[parent not found: <<83o8idkehc.fsf@gnu.org>]
[parent not found: <<83mtxxkcwk.fsf@gnu.org>]
* bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face [not found] ` <<83mtxxkcwk.fsf@gnu.org> @ 2020-12-28 18:54 ` Drew Adams 2020-12-28 19:34 ` Eli Zaretskii 0 siblings, 1 reply; 25+ messages in thread From: Drew Adams @ 2020-12-28 18:54 UTC (permalink / raw) To: Eli Zaretskii, drew.adams; +Cc: larsi, stefan, triska, 45428 > > > Shouldn't that just mean that the bug remains open? > > I'm not sure I agree that there is a bug. > > Or maybe I should turn the table and ask: what bug do you see with > this recipe, and what would you like to see instead? > > To be specific, here's the recipe: > emacs -Q > M-x font-lock-mode RET > M-: (insert (propertize "hello" 'face (quote (quote '(:height 10.0))))) RET Yes, I was using such a recipe to follow this bug. I see the same thing that I see when I use this: (insert (propertize "hello" 'face '(:height 10.0))) That second sexp follows the description (doc) of `propertize'. The first sexp does not. The bug, IMO, is that this is not "a sequence of PROPERY VALUE pairs...", which is what the doc says it should be: (quote (quote '(:height 10.0))) I wouldn't think of this as a doc bug because (1) this behavior is so unusual, and (2) I see no reason for it - no advantage in any way. Wrt #1: nowhere else, AFAIK, do we accept (quote (quote (quote SEXP))) or (quote (quote (quote (quote (quote SEXP))))) or <add more `quote' ...> as a substitute for SEXP. Those sexps are certainly are not equivalent for `eval'. We don't do that anywhere else, and I don't see why we should do it here (or anywhere)? I asked whether there's some special reason we should. You've said, I think, that you too see no reason why this is done, except the possible historical one of it having just happened by "accident". That's not a good reason for keeping this exceptional (I'd say bugged) behavior, IMO. That's all. ^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face 2020-12-28 18:54 ` Drew Adams @ 2020-12-28 19:34 ` Eli Zaretskii 0 siblings, 0 replies; 25+ messages in thread From: Eli Zaretskii @ 2020-12-28 19:34 UTC (permalink / raw) To: Drew Adams; +Cc: larsi, stefan, triska, 45428 > Date: Mon, 28 Dec 2020 10:54:58 -0800 (PST) > From: Drew Adams <drew.adams@oracle.com> > Cc: larsi@gnus.org, stefan@marxist.se, triska@metalevel.at, > 45428@debbugs.gnu.org > > I see the same thing that I see when I use this: > > (insert (propertize "hello" 'face '(:height 10.0))) Not exactly the same, see below. > The bug, IMO, is that this is not "a sequence of > PROPERY VALUE pairs...", which is what the doc > says it should be: > > (quote (quote '(:height 10.0))) Right, it's not. > I wouldn't think of this as a doc bug because (1) > this behavior is so unusual Which behavior are you alluding to here? and what is the "doc bug", exactly? > Wrt #1: nowhere else, AFAIK, do we accept > (quote (quote (quote SEXP))) > or (quote (quote (quote (quote (quote SEXP))))) > or <add more `quote' ...> as a substitute for SEXP. We don't "accept" it here, either. > We don't do that anywhere else, and I don't see > why we should do it here (or anywhere)? We don't. Please look in *Messages*, and you will see that. > You've said, I think, that you too see no reason > why this is done, except the possible historical > one of it having just happened by "accident". I'm beginning to think that we were talking about two different instances of "this". ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <<<<m2tusa3vzm.fsf@metalevel.at>]
[parent not found: <<<<87eejc9pnm.fsf@gnus.org>]
[parent not found: <<<<CADwFkm=Q9P-a+PJdiQzGWU9PkV1BhTEw9V4GPcFRAnuaFiUNVg@mail.gmail.com>]
[parent not found: <<<<5e99c39b-b67b-4184-a890-2cae38fb40de@default>]
[parent not found: <<<<87a6tzk5iv.fsf@metalevel.at>]
[parent not found: <<<<83h7o7kufk.fsf@gnu.org>]
[parent not found: <<<975c150b-99aa-4143-b057-8b5ec7caec19@default>]
[parent not found: <<<838s9jkqh7.fsf@gnu.org>]
[parent not found: <<fc9aea86-b07a-4f81-a442-019f610bb73a@default>]
[parent not found: <<835z4mkpvz.fsf@gnu.org>]
* bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face [not found] ` <<835z4mkpvz.fsf@gnu.org> @ 2020-12-28 17:45 ` Drew Adams 2020-12-28 17:49 ` Eli Zaretskii 0 siblings, 1 reply; 25+ messages in thread From: Drew Adams @ 2020-12-28 17:45 UTC (permalink / raw) To: Eli Zaretskii, Drew Adams; +Cc: larsi, stefan, triska, 45428 > > Or are you suggesting that the behavior was an accident? > > Yes! Thanks; that wasn't clear to me. > > what would be the argument for not fixing it > > That no one submitted a patch to reimplement that code in a way that > won't allow such constructs. Shouldn't that just mean that the bug remains open? Not having a fix submitted yet doesn't seem like a good argument for deciding not to fix something. Or did you perhaps mean that it's not an argument for not fixing it, but it's (just) an explanation for why it's not being fixed now? ^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face 2020-12-28 17:45 ` Drew Adams @ 2020-12-28 17:49 ` Eli Zaretskii 2020-12-28 18:23 ` Eli Zaretskii 0 siblings, 1 reply; 25+ messages in thread From: Eli Zaretskii @ 2020-12-28 17:49 UTC (permalink / raw) To: Drew Adams; +Cc: larsi, stefan, triska, 45428 > Date: Mon, 28 Dec 2020 09:45:20 -0800 (PST) > From: Drew Adams <drew.adams@oracle.com> > Cc: triska@metalevel.at, drew.adams@oracle.com, larsi@gnus.org, > stefan@marxist.se, 45428@debbugs.gnu.org > > Shouldn't that just mean that the bug remains open? I'm not sure I agree that there is a bug. ^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face 2020-12-28 17:49 ` Eli Zaretskii @ 2020-12-28 18:23 ` Eli Zaretskii 0 siblings, 0 replies; 25+ messages in thread From: Eli Zaretskii @ 2020-12-28 18:23 UTC (permalink / raw) To: drew.adams; +Cc: larsi, stefan, triska, 45428 > Date: Mon, 28 Dec 2020 19:49:35 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: larsi@gnus.org, stefan@marxist.se, triska@metalevel.at, > 45428@debbugs.gnu.org > > > Date: Mon, 28 Dec 2020 09:45:20 -0800 (PST) > > From: Drew Adams <drew.adams@oracle.com> > > Cc: triska@metalevel.at, drew.adams@oracle.com, larsi@gnus.org, > > stefan@marxist.se, 45428@debbugs.gnu.org > > > > Shouldn't that just mean that the bug remains open? > > I'm not sure I agree that there is a bug. Or maybe I should turn the table and ask: what bug do you see with this recipe, and what would you like to see instead? To be specific, here's the recipe: emacs -Q M-x font-lock-mode RET M-: (insert (propertize "hello" 'face (quote (quote '(:height 10.0))))) RET ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <<m2tusa3vzm.fsf@metalevel.at>]
[parent not found: <<87eejc9pnm.fsf@gnus.org>]
[parent not found: <<CADwFkm=Q9P-a+PJdiQzGWU9PkV1BhTEw9V4GPcFRAnuaFiUNVg@mail.gmail.com>]
[parent not found: <<5e99c39b-b67b-4184-a890-2cae38fb40de@default>]
[parent not found: <<87a6tzk5iv.fsf@metalevel.at>]
[parent not found: <<83h7o7kufk.fsf@gnu.org>]
* bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face [not found] ` <<83h7o7kufk.fsf@gnu.org> @ 2020-12-27 19:06 ` Drew Adams 2020-12-27 19:18 ` Eli Zaretskii 0 siblings, 1 reply; 25+ messages in thread From: Drew Adams @ 2020-12-27 19:06 UTC (permalink / raw) To: Eli Zaretskii, Markus Triska; +Cc: larsi, stefan, 45428 > > In my own configuration and Emacs Lisp programs, I would strongly prefer > > to rely only on documented features of Emacs, and I would like Emacs to > > at least warn me if my code starts to rely on features that are not > > officially supported and hence may change more readily in the future. > > You should indeed rely on documented behavior. But that doesn't mean > Emacs cannot have undocumented behavior, especially when it is a side > effect of the specific implementation of some documented feature. Agreed. But what is the specific need for this particular undocumented behavior? That's the question relevant for this bug, I think. Does anyone even know why this undocumented, unlispy, and bizarre exception was made here? ^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face 2020-12-27 19:06 ` Drew Adams @ 2020-12-27 19:18 ` Eli Zaretskii 0 siblings, 0 replies; 25+ messages in thread From: Eli Zaretskii @ 2020-12-27 19:18 UTC (permalink / raw) To: Drew Adams; +Cc: larsi, stefan, triska, 45428 > Date: Sun, 27 Dec 2020 11:06:03 -0800 (PST) > From: Drew Adams <drew.adams@oracle.com> > Cc: drew.adams@oracle.com, larsi@gnus.org, stefan@marxist.se, > 45428@debbugs.gnu.org > > > You should indeed rely on documented behavior. But that doesn't mean > > Emacs cannot have undocumented behavior, especially when it is a side > > effect of the specific implementation of some documented feature. > > Agreed. But what is the specific need for this > particular undocumented behavior? Who said there's a need? AFAIU, it's just an implementation artifact. ^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face @ 2020-12-25 12:34 Markus Triska 2020-12-26 22:19 ` Lars Ingebrigtsen 2020-12-28 19:58 ` Andreas Schwab 0 siblings, 2 replies; 25+ messages in thread From: Markus Triska @ 2020-12-25 12:34 UTC (permalink / raw) To: 45428 In 39.12 Faces, the Emacs Lisp documentation states: One way to represent a face is as a property list of attributes, like ‘(:foreground "red" :weight bold)’. Such a list is called an “anonymous face”. And according to 5.9 Property Lists, a property list "is a list of paired elements.". Specifying the anonymous face (:height 10.0), i.e., a property list, works exactly as intended and documented when we invoke Emacs with: $ emacs -Q --eval '(font-lock-mode 0)' \ --eval "(insert (propertize \ \"hello\" \ 'face (quote (:height 10.0))))" Writing (quote (:height 10.0)) is equal to writing '(:height 10.0): (equal (quote (:height 10.0)) '(:height 10.0)) ==> t However, using multiple nested (quote ...) forms is not equivalent to using a single quote in general: (equal (quote (quote (:height 10.0))) '(:height 10.0)) ==> nil Yet, wrapping the face within multiple nested (quote ...) forms unexpectedly yields the same visual result as using a single quote form, namely (again) an enlarged "hello": $ emacs -Q --eval '(font-lock-mode 0)' \ --eval "(insert (propertize \ \"hello\" \ 'face (quote (quote '(:height 10.0)))))" In this case, the anonymous face is not specified as a property list, but as a symbolic expression of the form (quote (quote (quote ...))), and still works. Is this the intended result, and can we rely on it? If so, could you please document it? Issue #35005 is related to this. Thank you a lot! Markus In GNU Emacs 27.1 (build 1, x86_64-apple-darwin15.3.0, X toolkit, Xaw scroll bars) of 2020-12-12 built on mac Windowing system distributor 'The X.Org Foundation', version 11.0.11502000 System Description: Mac OS X 10.11.3 ^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face 2020-12-25 12:34 Markus Triska @ 2020-12-26 22:19 ` Lars Ingebrigtsen 2020-12-27 4:16 ` Stefan Kangas 2020-12-28 19:58 ` Andreas Schwab 1 sibling, 1 reply; 25+ messages in thread From: Lars Ingebrigtsen @ 2020-12-26 22:19 UTC (permalink / raw) To: Markus Triska; +Cc: 45428 Markus Triska <triska@metalevel.at> writes: > In this case, the anonymous face is not specified as a property list, > but as a symbolic expression of the form (quote (quote (quote ...))), > and still works. Is this the intended result, and can we rely on it? If > so, could you please document it? I think it's just that Emacs is liberal in what it receives, and tries to muddle through. For instance, the following works fine: (insert (propertize "hello" 'face (list (list (list :height 10.0))))) But this isn't something we'd want to document -- we document the recommended forms to use, even if Emacs is more liberal in what it accepts, sometimes. Anybody else got an opinion here? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face 2020-12-26 22:19 ` Lars Ingebrigtsen @ 2020-12-27 4:16 ` Stefan Kangas 2020-12-27 4:47 ` Drew Adams 0 siblings, 1 reply; 25+ messages in thread From: Stefan Kangas @ 2020-12-27 4:16 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 45428, Markus Triska [-- Attachment #1: Type: text/plain, Size: 721 bytes --] (Sorry if formatting is messed up as I'm replying from my phone.) I think it makes sense to be forgiving here as this is something users will commonly configure. As long as it doesn't give inconsistent results (which doesn't seem to be the case) it is probably better to be liberal in what we accept. Also, if we change it now, user configurations will break without AFAICT a strong reason. So I'd tend to say keep what we have now. IMO, we should still not document this just in case we find a strong reason to change it later. But we could perhaps add a unit test for this with a comment explaining why we try to accept this for the time being. Or we just do nothing and close the bug as wontfix. Just my two cents. [-- Attachment #2: Type: text/html, Size: 898 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face 2020-12-27 4:16 ` Stefan Kangas @ 2020-12-27 4:47 ` Drew Adams 2020-12-27 8:38 ` Markus Triska 0 siblings, 1 reply; 25+ messages in thread From: Drew Adams @ 2020-12-27 4:47 UTC (permalink / raw) To: Stefan Kangas, Lars Ingebrigtsen; +Cc: 45428, Markus Triska > I think it makes sense to be forgiving here as this is something users will commonly configure. As long as it doesn't give inconsistent results (which doesn't seem to be the case) it is probably better to be liberal in what we accept. Also, if we change it now, user configurations will break without AFAICT a strong reason. So I'd tend to say keep what we have now. > IMO, we should still not document this just in case we find a strong reason to change it later. But we could perhaps add a unit test for this with a comment explaining why we try to accept this for the time being. Or we just do nothing and close the bug as wontfix. > Just my two cents. My 2c differ. To me this is just a bug, and should be fixed. The behavior should follow the doc. More importantly, it should follow the general behavior of Lisp evaluation. Why would we treat '''foo, '''''foo, etc. the same as 'foo? The answer is that we wouldn't, generally, and we don't. I see no advantage whatsoever in "being forgiving" here - what's that about? This is a bad precedent, and I don't see any particular reason for it here. By "particular", I mean what's special about such "forgiveness" in the case of anonymous face sexps? Why create a special case? And what's the advantage for users? The argument that this behavior is longstanding is a stronger argument (because it's stronger than zero), but my 2c says it's not particularly strong here. Maybe there's a good argument for this odd treatment. I haven't see one so far. ^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face 2020-12-27 4:47 ` Drew Adams @ 2020-12-27 8:38 ` Markus Triska 2020-12-27 17:52 ` Eli Zaretskii 0 siblings, 1 reply; 25+ messages in thread From: Markus Triska @ 2020-12-27 8:38 UTC (permalink / raw) To: Drew Adams; +Cc: Lars Ingebrigtsen, Stefan Kangas, 45428 Drew Adams <drew.adams@oracle.com> writes: > My 2c differ. To me this is just a bug, and should be > fixed. The behavior should follow the doc. More > importantly, it should follow the general behavior of > Lisp evaluation. Why would we treat '''foo, '''''foo, > etc. the same as 'foo? The answer is that we wouldn't, > generally, and we don't. I agree with this. Is there any other place in Emacs where '''X is treated the same as 'X? As far as I can tell, this seems quite specific to faces. How is this happening? Is there special logic in Emacs that enables this, and is it used for other parts too? In my own configuration and Emacs Lisp programs, I would strongly prefer to rely only on documented features of Emacs, and I would like Emacs to at least warn me if my code starts to rely on features that are not officially supported and hence may change more readily in the future. All the best, Markus ^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face 2020-12-27 8:38 ` Markus Triska @ 2020-12-27 17:52 ` Eli Zaretskii 0 siblings, 0 replies; 25+ messages in thread From: Eli Zaretskii @ 2020-12-27 17:52 UTC (permalink / raw) To: Markus Triska; +Cc: larsi, stefan, 45428 > From: Markus Triska <triska@metalevel.at> > Date: Sun, 27 Dec 2020 09:38:32 +0100 > Cc: Lars Ingebrigtsen <larsi@gnus.org>, Stefan Kangas <stefan@marxist.se>, > 45428@debbugs.gnu.org > > In my own configuration and Emacs Lisp programs, I would strongly prefer > to rely only on documented features of Emacs, and I would like Emacs to > at least warn me if my code starts to rely on features that are not > officially supported and hence may change more readily in the future. You should indeed rely on documented behavior. But that doesn't mean Emacs cannot have undocumented behavior, especially when it is a side effect of the specific implementation of some documented feature. ^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face 2020-12-25 12:34 Markus Triska 2020-12-26 22:19 ` Lars Ingebrigtsen @ 2020-12-28 19:58 ` Andreas Schwab 1 sibling, 0 replies; 25+ messages in thread From: Andreas Schwab @ 2020-12-28 19:58 UTC (permalink / raw) To: Markus Triska; +Cc: 45428 On Dez 25 2020, Markus Triska wrote: > In this case, the anonymous face is not specified as a property list, > but as a symbolic expression of the form (quote (quote (quote ...))), > and still works. Is this the intended result, and can we rely on it? If > so, could you please document it? It is already documented, see (elisp) Special Properties. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2020-12-30 2:54 UTC | newest] Thread overview: 25+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <<<m2tusa3vzm.fsf@metalevel.at> [not found] ` <<<87eejc9pnm.fsf@gnus.org> [not found] ` <<<CADwFkm=Q9P-a+PJdiQzGWU9PkV1BhTEw9V4GPcFRAnuaFiUNVg@mail.gmail.com> [not found] ` <<<5e99c39b-b67b-4184-a890-2cae38fb40de@default> [not found] ` <<<87a6tzk5iv.fsf@metalevel.at> [not found] ` <<<83h7o7kufk.fsf@gnu.org> [not found] ` <<975c150b-99aa-4143-b057-8b5ec7caec19@default> [not found] ` <<838s9jkqh7.fsf@gnu.org> 2020-12-27 19:56 ` bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face Drew Adams 2020-12-28 13:43 ` Eli Zaretskii [not found] <<<<<<m2tusa3vzm.fsf@metalevel.at> [not found] ` <<<<<<87eejc9pnm.fsf@gnus.org> [not found] ` <<<<<<CADwFkm=Q9P-a+PJdiQzGWU9PkV1BhTEw9V4GPcFRAnuaFiUNVg@mail.gmail.com> [not found] ` <<<<<<5e99c39b-b67b-4184-a890-2cae38fb40de@default> [not found] ` <<<<<<87a6tzk5iv.fsf@metalevel.at> [not found] ` <<<<<<83h7o7kufk.fsf@gnu.org> [not found] ` <<<<<975c150b-99aa-4143-b057-8b5ec7caec19@default> [not found] ` <<<<<838s9jkqh7.fsf@gnu.org> [not found] ` <<<<fc9aea86-b07a-4f81-a442-019f610bb73a@default> [not found] ` <<<<835z4mkpvz.fsf@gnu.org> [not found] ` <<<5dfff982-e496-46fe-9efd-1e0edd4f0be8@default> [not found] ` <<<83o8idkehc.fsf@gnu.org> [not found] ` <<<83mtxxkcwk.fsf@gnu.org> [not found] ` <<9a600718-7caf-4ad0-a664-0ebafba63e57@default> [not found] ` <<83im8lk9lp.fsf@gnu.org> 2020-12-28 20:44 ` Drew Adams 2020-12-29 14:53 ` Eli Zaretskii 2020-12-29 16:40 ` Markus Triska 2020-12-29 17:17 ` Eli Zaretskii 2020-12-29 18:39 ` Markus Triska 2020-12-29 19:41 ` Eli Zaretskii 2020-12-29 18:27 ` Drew Adams 2020-12-29 19:39 ` Eli Zaretskii 2020-12-30 2:54 ` Lars Ingebrigtsen [not found] <<<<<m2tusa3vzm.fsf@metalevel.at> [not found] ` <<<<<87eejc9pnm.fsf@gnus.org> [not found] ` <<<<<CADwFkm=Q9P-a+PJdiQzGWU9PkV1BhTEw9V4GPcFRAnuaFiUNVg@mail.gmail.com> [not found] ` <<<<<5e99c39b-b67b-4184-a890-2cae38fb40de@default> [not found] ` <<<<<87a6tzk5iv.fsf@metalevel.at> [not found] ` <<<<<83h7o7kufk.fsf@gnu.org> [not found] ` <<<<975c150b-99aa-4143-b057-8b5ec7caec19@default> [not found] ` <<<<838s9jkqh7.fsf@gnu.org> [not found] ` <<<fc9aea86-b07a-4f81-a442-019f610bb73a@default> [not found] ` <<<835z4mkpvz.fsf@gnu.org> [not found] ` <<5dfff982-e496-46fe-9efd-1e0edd4f0be8@default> [not found] ` <<83o8idkehc.fsf@gnu.org> [not found] ` <<83mtxxkcwk.fsf@gnu.org> 2020-12-28 18:54 ` Drew Adams 2020-12-28 19:34 ` Eli Zaretskii [not found] <<<<m2tusa3vzm.fsf@metalevel.at> [not found] ` <<<<87eejc9pnm.fsf@gnus.org> [not found] ` <<<<CADwFkm=Q9P-a+PJdiQzGWU9PkV1BhTEw9V4GPcFRAnuaFiUNVg@mail.gmail.com> [not found] ` <<<<5e99c39b-b67b-4184-a890-2cae38fb40de@default> [not found] ` <<<<87a6tzk5iv.fsf@metalevel.at> [not found] ` <<<<83h7o7kufk.fsf@gnu.org> [not found] ` <<<975c150b-99aa-4143-b057-8b5ec7caec19@default> [not found] ` <<<838s9jkqh7.fsf@gnu.org> [not found] ` <<fc9aea86-b07a-4f81-a442-019f610bb73a@default> [not found] ` <<835z4mkpvz.fsf@gnu.org> 2020-12-28 17:45 ` Drew Adams 2020-12-28 17:49 ` Eli Zaretskii 2020-12-28 18:23 ` Eli Zaretskii [not found] <<m2tusa3vzm.fsf@metalevel.at> [not found] ` <<87eejc9pnm.fsf@gnus.org> [not found] ` <<CADwFkm=Q9P-a+PJdiQzGWU9PkV1BhTEw9V4GPcFRAnuaFiUNVg@mail.gmail.com> [not found] ` <<5e99c39b-b67b-4184-a890-2cae38fb40de@default> [not found] ` <<87a6tzk5iv.fsf@metalevel.at> [not found] ` <<83h7o7kufk.fsf@gnu.org> 2020-12-27 19:06 ` Drew Adams 2020-12-27 19:18 ` Eli Zaretskii 2020-12-25 12:34 Markus Triska 2020-12-26 22:19 ` Lars Ingebrigtsen 2020-12-27 4:16 ` Stefan Kangas 2020-12-27 4:47 ` Drew Adams 2020-12-27 8:38 ` Markus Triska 2020-12-27 17:52 ` Eli Zaretskii 2020-12-28 19:58 ` Andreas Schwab
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.