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

[Eli Zaretskii <eliz@gnu.org>]

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