bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face

bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face

[Drew Adams]

> > 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?

bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face

[Eli Zaretskii]

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

bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face

[Drew Adams]

> > 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?

bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face

[Eli Zaretskii]

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

bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face

[Markus Triska]

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

bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face

[Eli Zaretskii]

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

bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face

[Markus Triska]

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

bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face

[Eli Zaretskii]

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

bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face

[Drew Adams]

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

bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face

[Eli Zaretskii]

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

bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face

[Lars Ingebrigtsen]

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

bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face

[Drew Adams]

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

bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face

[Eli Zaretskii]

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

bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face

[Drew Adams]

> > 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?

bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face

[Eli Zaretskii]

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

bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face

[Eli Zaretskii]

> 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

bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face

[Drew Adams]

> > > 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?

bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face

[Eli Zaretskii]

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

bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face

[Markus Triska]

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

bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face

[Lars Ingebrigtsen]

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

bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face

[Stefan Kangas]

[-- 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 --]

bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face

[Drew Adams]

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

bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face

[Markus Triska]

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

bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face

[Eli Zaretskii]

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

bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face

[Andreas Schwab]

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