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

[Ivan Shmakov <ivan@siamics.net>]

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

[…]

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

[…]

-- 
FSF associate member #7257  np. Coming Home — Iron Maiden  B6A0 230E 334A