[Top][All Lists]

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

Re: intern-soft, find-face/get-face, and facep for determining faces' de

From: Brian Palmer
Subject: Re: intern-soft, find-face/get-face, and facep for determining faces' definedness
Date: Tue, 2 Nov 2004 00:28:41 -0700

On Tue, 02 Nov 2004 15:14:08 +0900, Stephen J. Turnbull
<address@hidden> wrote:
> >>>>> "Brian" == Brian Palmer <address@hidden> writes:
>     Brian> Xemacs developers, is there any reason that xemacs's facep
>     Brian> should not be extended to take either face objects or names
>     Brian> (so, for example, (facep 'bold) => t )?
> Yes, there is.  That's what `find-face' is for.  We'd still probably
> want a way to distinguish between face names and face objects, and
> proving that (a) we don't currently have any code that depends on
> `facep''s behavior, and (b) that we'd never want it, is more work than
> this is worth.

Hmm. While that's fair enough, I think (facep 'bold) is a fairly 
intuitive thing to do, and returning nil is a surprise. So the name 
seems off to me.  I suppose for historical reasons...
>     Brian> Or could find-face/get-face be implemented for emacs? (They
>     Brian> seem like probably useful functions to me).
> Your version wasn't quite right; it's
> (defalias 'find-face 'facep)

find-face should not return a boolean, if it's going to be used portably
across the emacs branches. So maybe
(defun find-face (face) (if (facep face) (make-face face) nil))

> (defun get-face (face-or-name)
>   (or (find-face face-or-name)
>       (error "Face %s doesn't exist" face-or-name)))

True enough, that, for current compatibility. Ideally there'd be a 
structured error condition, though (as error's docstring says, 
"Although this usage  of `error' is very common, it is deprecated because it
totally defeats the purpose of having structured errors." )

reply via email to

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