bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#19903: 24.4; wrong-type-argument symbolp "bold" during enriched-encode
Date: Wed, 25 Feb 2015 19:43:52 +0200

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]