bug#19903: 24.4; wrong-type-argument symbolp "bold" during enriched-encode

[Eli Zaretskii]

> From: Ivan Shmakov <ivan@siamics.net>
> Date: Wed, 25 Feb 2015 06:20:36 +0000
> 
>  > I don't think internal functions should cater to UI issues, unless
>  > they are themselves interactive.
> 
>       I’m unsure where you see an UI issue here?  The issue, as
>       originally reported, is that face-attribute fails to handle
>       string-named faces, which are considered perfectly valid by the
>       rest of Emacs (including, say, facep and the display engine.)

Accepting strings instead of symbols is a convenience feature for
users, so it's a UI issue.

>       From there, we can go different ways, including:
> 
>       • bury our head in the sand and pretend there’s no issue;

I don't think anybody suggested that; I certainly didn't.  If you are
now suggesting it, then no, I don't think we should.

>       • patch one or two of the functions which can be used to add
>         such faces – to either silently (or not so) replace them with
>         the respective symbol-named ones, /or/ to signal an error;
>         this won’t prevent, however, the use of put-text-property and
>         the likes of it to achieve that same effect;

I don't see why we need to spread this so wide.  Making facemenu.el
behave consistently sounds good enough, and will solve the original
report.

>  > If we keep this confined to interactive functions, how many such
>  > functions in facemenu.el will have to be changed?  If not too many,
>  > I'm inclined to keep this there.
> 
>       I believe that facemenu-add-face is the only function which can
>       be used to add a string-named face /interactively/, as it reads
>       an arbitrary Lisp form for the face.  (See also #18369.)

Yes, but how many don't?

> 
>       The original report, however, was concerned with the use of
>       facemenu-add-face from Lisp, and there’re still a plenty of ways
>       to hit this issue apart from using facemenu-add-face with a
>       string argument.

I don't think we need to consider them.