[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.
- bug#19903: 24.4; wrong-type-argument symbolp "bold" during enriched-encode, (continued)
- bug#19903: 24.4; wrong-type-argument symbolp "bold" during enriched-encode, Eli Zaretskii, 2015/02/20
- bug#19903: 24.4; wrong-type-argument symbolp "bold" during enriched-encode, Stefan Monnier, 2015/02/20
- bug#19903: 24.4; wrong-type-argument symbolp "bold" during enriched-encode, Ivan Shmakov, 2015/02/20
- bug#19903: 24.4; wrong-type-argument symbolp "bold" during enriched-encode, Stefan Monnier, 2015/02/20
- bug#19903: 24.4; wrong-type-argument symbolp "bold" during enriched-encode, Ivan Shmakov, 2015/02/20
- bug#19903: 24.4; wrong-type-argument symbolp "bold" during enriched-encode, Ivan Shmakov, 2015/02/21
- bug#19903: 24.4; wrong-type-argument symbolp "bold" during enriched-encode, Eli Zaretskii, 2015/02/21
- bug#19903: 24.4; wrong-type-argument symbolp "bold" during enriched-encode, Ivan Shmakov, 2015/02/25
- bug#19903: 24.4; wrong-type-argument symbolp "bold" during enriched-encode, Eli Zaretskii, 2015/02/25
- bug#19903: 24.4; wrong-type-argument symbolp "bold" during enriched-encode, Ivan Shmakov, 2015/02/25
- bug#19903: 24.4; wrong-type-argument symbolp "bold" during enriched-encode,
Eli Zaretskii <=
- bug#19903: 24.4; wrong-type-argument symbolp "bold" during enriched-encode, Ivan Shmakov, 2015/02/25
- bug#19912: facemenu-add-face: does not handle 'face being set to a property list, Ivan Shmakov, 2015/02/21
- bug#19912: facemenu-add-face: does not handle 'face being set to a property list, Ivan Shmakov, 2015/02/25
- bug#19912: facemenu-add-face: does not handle 'face being set to a property list, Ivan Shmakov, 2015/02/25
- bug#19912: facemenu-add-face: does not handle 'face being set to a property list, Ivan Shmakov, 2015/02/26
bug#19903: 24.4; Emacs fails to save enriched buffer with error message `wrong-type-argument symbolp "bold"', Eli Zaretskii, 2015/02/20