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 17:10:13 +0000
> 
> >>>>> Eli Zaretskii <eliz@gnu.org> writes:
> >>>>> From: Ivan Shmakov  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.
> 
> 	Could you please elaborate on this?  Specifically, does this
> 	apply to the interactive or non-interactive use (or both) of
> 	facemenu-add-face?

Both.

>  >>> 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?
> 
> 	One another (facemenu-set-face) uses read-face-name, which in
> 	turn explicitly passes user input through ‘intern’.
> 
> 	Then, facemenu-set-face-from-menu uses last-command-event (when
> 	called interactively), assumes it’s a symbol, and uses it either
> 	as a face directly /or/ (should its name begin with fg: or bg:)
> 	as the cdr for a cons cell face.  (The facemenu-set-foreground
> 	and facemenu-set-background commands rely on this.)
> 
> 	Per my reading of the code, no other command there accepts
> 	user-specified faces when used interactively.

So only one function needs a change?  If so, I think that's what we
should do.