intern-soft, find-face/get-face, and facep for determining faces' definedness

intern-soft, find-face/get-face, and facep for determining faces' definedness

[Brian Palmer]

In vc.el, vc-annotate-lines, the following binding is established:
(face (or (intern-soft face-name)
	  (let ((tmp-face (make-face (intern face-name))))
	    (set-face-foreground tmp-face (cdr color))
	    (if vc-annotate-background
		(set-face-background tmp-face
				     vc-annotate-background))
	    tmp-face))); Return the face

This is true in both emacs and the recently-synced xemacs vc.el (a
similar issue was present in the older xemacs code). This seems
frankly wrong to me; it doesn't matter whether the symbol has been
interned, it matters whether the face has been defined. A fix would be
in emacs to use (facep face-name) and in xemacs to use (find-face
face-name), instead.

The two different approaches seems troublesome to me; it'd be nice if
the same functions could be used in both . Xemacs developers, is there
any reason that xemacs's facep should not be extended to take either
face objects or names (so, for example, (facep 'bold) => t )? Or 
could find-face/get-face be implemented for emacs? (They seem like
probably useful functions to me). It seems like it'd be as simple as

(if (facep FACE) 
    (make-face FACE) 
  (cerror 'nonexistent-face (format "Face %s doesn't exist" FACE)))

Or, both. Thoughts appreciated.

-- 
I'm awfully glad I'm a Beta, because I don't work so hard.

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

[Stephen J. Turnbull]

>>>>> "Brian" == Brian Palmer <bpalmer@rescomp.stanford.edu> writes:

    Brian> In vc.el, vc-annotate-lines, the following binding is established:
    Brian> (face (or (intern-soft face-name)
[...]
    Brian> A fix would be in emacs to use (facep face-name) and [...] xemacs to use (find-face
    Brian> face-name), instead.

This looks correct.

    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.

    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)

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

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

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

[Brian Palmer]

On Tue, 02 Nov 2004 15:14:08 +0900, Stephen J. Turnbull
<stephen@xemacs.org> wrote:
> >>>>> "Brian" == Brian Palmer <bpalmer@rescomp.stanford.edu> 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." )

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

[Miles Bader]

Brian Palmer <bpalmer@gmail.com> writes:
> (defun find-face (face) (if (facep face) (make-face face) nil))

In Emacs this is equivalent to 

   (defun find-face (face) (and (facep face) face))

Why exactly do you want to use `find-face' anyway?  Why not just avoid
using `facep' except in a boolean context?

-Miles
-- 
Quidquid latine dictum sit, altum viditur.

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

[Brian Palmer]

On Tue, 02 Nov 2004 16:45:38 +0900, Miles Bader <miles@lsi.nec.co.jp> wrote:
> Brian Palmer <bpalmer@gmail.com> writes:
> In Emacs this is equivalent to
> 
>    (defun find-face (face) (and (facep face) face))
> 
> Why exactly do you want to use `find-face' anyway?  Why not just avoid
> using `facep' except in a boolean context?

Well, find-face returns a face object in xemacs. I'm proposing a new function 
to add to gnu emacs so that there's <rant>one fewer arbitrary
difference between
emacs and xemacs that causes inconvenience and unnecessary friction for 
those of us who code third-party applications or help users of both xemacs and 
emacs</rant>. If find-face in emacs didn't return a face object, it
wouldn't be doing
a very good job of compatibility, now. 

The proposed patch I outlined, and the stupid way in which it has to
differ across
emacs and xemacs, shows that there's a use for improving compatibility.

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

[Miles Bader]

Brian Palmer <bpalmer@gmail.com> writes:
> If find-face in emacs didn't return a face object, it wouldn't be
> doing a very good job of compatibility, now.

What's a "face object" in Emacs?  [Indeed, what's a "face object" in Xemacs?]

How are they different than a face name (other than what `facep' returns
in Xemacs)?

Given that Xemacs has a differing definition of facep requiring one to
use `find-face' instead, would an Emacs version:

   (defun find-face (face) (and (facep face) face))

do the job?

-Miles
-- 
[|nurgle|]  ddt- demonic? so quake will have an evil kinda setting? one that
            will  make every christian in the world foamm at the mouth?
[iddt]      nurg, that's the goal

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

[Brian Palmer]

On Tue, 02 Nov 2004 18:08:17 +0900, Miles Bader <miles@lsi.nec.co.jp> wrote:
> Brian Palmer <bpalmer@gmail.com> writes:
> > If find-face in emacs didn't return a face object, it wouldn't be
> > doing a very good job of compatibility, now.
> 
> What's a "face object" in Emacs?  [Indeed, what's a "face object" in Xemacs?]

I don't really know.  Some object that contains all of the required
face attributes,
I'm assuming. E.g., 

(get-face 'bold)
#<face bold "Bold text.">

So basically the difference between a buffer and a buffer-name. But I haven't
looked at the C code implementing faces
 
> Given that Xemacs has a differing definition of facep requiring one to
> use `find-face' instead, would an Emacs version:
> 
>    (defun find-face (face) (and (facep face) face))
> 
> do the job?

I think so, as long as emacs allows a face-name everywhere a face is 
permitted.

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

[Miles Bader]

Brian Palmer <bpalmer@gmail.com> writes:
>> Given that Xemacs has a differing definition of facep requiring one to
>> use `find-face' instead, would an Emacs version:
>> 
>>    (defun find-face (face) (and (facep face) face))
>> 
>> do the job?
>
> I think so, as long as emacs allows a face-name everywhere a face is 
> permitted.

For most purposes, Emacs doesn't have a special face type, it only has
face-names.

It's also possible to get a lisp vector containing face attributes, but
this is typically only useful for a few special tasks -- most interfaces
want a face-name).

To be reasonably compatible with Xemacs, it would be necessary to know
what exactly a face-object (such as returned by `find-face') is useful
for, and I don't.  But my guess is that a face-name is closer than a
face-vector.

-Miles
-- 
Saa, shall we dance?  (from a dance-class advertisement)

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

[Stephen J. Turnbull]

>>>>> "Miles" == Miles Bader <miles@lsi.nec.co.jp> writes:

    Miles> To be reasonably compatible with Xemacs, it would be
    Miles> necessary to know what exactly a face-object (such as
    Miles> returned by `find-face') is useful for, and I don't.

As an optimization.  You can avoid a table lookup if you have the
object.  We also have truly anonymous temporary faces, which get
garbage collected simply by dropping them on the floor, as they never
get entered into any tables.  Another optimization; I guess you could
use gensyms and key-weak hash tables to get the same effect nowadays.
Offhand I'd guess the other APIs (ie, except for `facep) all accept
either a face name or a face object.

The only tricky thing about find-face is that it needs to be
idempotent:

(Assert (null (find-face (find-face [nope]))))    ; not a symbol
(Assert (null (find-face (find-face nil))))       ; a special non-face symbol
(Assert (null (find-face (find-face (gensym)))))  ; a non-face symbol
(Assert (eq (find-face 'default) (find-face (find-face 'default))))

I think that gives full coverage.  Your definition of find-face should
be fine, except possibly for XEmacs APIs Emacs doesn't have.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

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

[Miles Bader]

On Tue, Nov 02, 2004 at 09:06:56PM +0900, Stephen J. Turnbull wrote:
> We also have truly anonymous temporary faces, which get
> garbage collected simply by dropping them on the floor, as they never
> get entered into any tables.

As an aside, I've long wanted to add anonymous faces to Emacs; a cursory
investigation suggests that simply allowing lisp `face vectors' to be used in
a few places (skipping the name->vector lookup) would actually work.  However
the huge amount of backward-compatibility hair in Emacs' face machinery
always makes such things a bit touch-n-go...

[I don't think the name lookup efficiency is actually much of an issue though;
my reason is more to avoid the necessity of naming faces.]

-Miles
-- 
I'd rather be consing.

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

[Oliver Scholz]

Miles Bader <miles@gnu.org> writes:

> On Tue, Nov 02, 2004 at 09:06:56PM +0900, Stephen J. Turnbull wrote:
>> We also have truly anonymous temporary faces, which get
>> garbage collected simply by dropping them on the floor, as they never
>> get entered into any tables.
>
> As an aside, I've long wanted to add anonymous faces to Emacs;

Don't we have them already?

(progn (switch-to-buffer (generate-new-buffer "*tmp*"))
       (insert
        (propertize "lirum larum"
                    'face
                    '(face :foreground "blue" :inherit variable-pitch))))

Or am I missing something?


    Oliver
-- 
Oliver Scholz               16 Brumaire an 213 de la Révolution
Ostendstr. 61               Liberté, Egalité, Fraternité!
60314 Frankfurt a. M.       

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

[Stephen J. Turnbull]

>>>>> "Miles" == Miles Bader <miles@lsi.nec.co.jp> writes:

    Miles> Brian Palmer <bpalmer@gmail.com> writes:

    >> If find-face in emacs didn't return a face object, it wouldn't
    >> be doing a very good job of compatibility, now.

    Miles> What's a "face object" in Emacs?

A symbol, I should think.  I was confused by the fact that `facep'
returns a vector of length 17 whose first element is the symbol 'face.
However, I would guess that that's a useless artifact of the
implementation, since (facep (facep 'bold)) is nil.

    Miles> [Indeed, what's a "face object" in Xemacs?]

A C structure wrapped in Lisp housekeeping information that implements
a face.  I'm not sure why they were exposed to Lisp in the first
place; I suspect to avoid repeated lookups in code that compares faces
to determine if they contrast and the like.  Probably a premature
optimization.

    Miles> How are they different than a face name (other than what
    Miles> `facep' returns in Xemacs)?

A face name is a symbol.  A face object is a data structure.

    Miles> Given that Xemacs has a differing definition of facep
    Miles> requiring one to use `find-face' instead, would an Emacs
    Miles> version:

    Miles>    (defun find-face (face) (and (facep face) face))

    Miles> do the job?

Yes.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

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

[Stefan]

Miles> What's a "face object" in Emacs?
> A symbol, I should think.  I was confused by the fact that `facep'
> returns a vector of length 17 whose first element is the symbol 'face.
> However, I would guess that that's a useless artifact of the
> implementation, since (facep (facep 'bold)) is nil.

I've never seen the vector used in Elisp for anything, so yes: it's just
a useless (and arguably ugly) artifact of the implementation.

Miles> [Indeed, what's a "face object" in Xemacs?]

> A C structure wrapped in Lisp housekeeping information that implements
> a face.  I'm not sure why they were exposed to Lisp in the first
> place; I suspect to avoid repeated lookups in code that compares faces
> to determine if they contrast and the like.  Probably a premature
> optimization.

I doubt the motivation was optimization.  I think it had more to do with
philosophical convictions.

> A face name is a symbol.  A face object is a data structure.

I still don't understand why (facep 'foo) returns nil, even though

   (put-text-property (point) (+ 10 (point)) 'face 'foo)
and
   (set-face-foreground 'foo "red")

work just fine.  I think `facep' should return non-nil iff the parameter can
be used at those places where faces are expected, so it should return
non-nil for symbols (assuming the symbol is indeed the name of an existing
face, of course).
Just like (progn (fset 'foobar (make-keymap)) (keymapp 'foobar)) return
t rather than nil.


        Stefan

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

[Miles Bader]

On Tue, Nov 02, 2004 at 07:01:49AM -0500, Stefan wrote:
> I've never seen the vector used in Elisp for anything, so yes: it's just
> a useless (and arguably ugly) artifact of the implementation.

They actually are used though, e.g., in `face-attribute'.  In that case they
are nice because they allow one to find the "final" value of a particular
face attribute.

However most lisp code can probably just use `face-attribute' instead.

-Miles
-- 
We are all lying in the gutter, but some of us are looking at the stars.
-Oscar Wilde

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

[Richard Stallman]

    I still don't understand why (facep 'foo) returns nil, even though

       (put-text-property (point) (+ 10 (point)) 'face 'foo)
    and
       (set-face-foreground 'foo "red")

    work just fine.

I don't understand what you mean here.  As far as I know, if (facep
'foo) returns nil, then (set-face-foreground 'foo "red") will signal
an error, "Invalid face".  Conversely, if you define foo as face, then
(facep 'foo) will return t.

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

[Stefan Monnier]

>     I still don't understand why (facep 'foo) returns nil, even though
>        (put-text-property (point) (+ 10 (point)) 'face 'foo)
>     and
>        (set-face-foreground 'foo "red")

>     work just fine.

> I don't understand what you mean here.  As far as I know, if (facep
> 'foo) returns nil, then (set-face-foreground 'foo "red") will signal
> an error, "Invalid face".  Conversely, if you define foo as face, then
> (facep 'foo) will return t.

Yes, that's what happens under Emacs.  I was talking about XEmacs, tho.


        Stefan

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

[Zajcev Evgeny]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>     I still don't understand why (facep 'foo) returns nil, even though
>>        (put-text-property (point) (+ 10 (point)) 'face 'foo)
>>     and
>>        (set-face-foreground 'foo "red")
>
>>     work just fine.
>
>> I don't understand what you mean here.  As far as I know, if (facep
>> 'foo) returns nil, then (set-face-foreground 'foo "red") will signal
>> an error, "Invalid face".  Conversely, if you define foo as face, then
>> (facep 'foo) will return t.
>
> Yes, that's what happens under Emacs.  I was talking about XEmacs,
> tho.

The thing is that XEmacsen `facep' returns non-nil only on face
objects, not on their names or anything else, however `get-face' does
all tricks - it returns face object getting face object or face name
or anything else as input.  Here is:

   (eq (get-face (get-face 'blue)) (get-face 'blue))
   => t

i.e. `get-face' behavious as 'identity if input is face object and
does some job in finding face object by its name if input is symbol
that denotes face (face's name).

Most of functions that deal with faces should use `(facep (get-face
<face>))' sexp to check face validity.

As described above I believe that `set-face-foreground' just does
`get-face' before operating on face.

-- 
lg

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

[Andreas Schwab]

Zajcev Evgeny <zevlg@yandex.ru> writes:

> Most of functions that deal with faces should use `(facep (get-face
> <face>))' sexp to check face validity.

Why do you need facep if get-face already did all validation?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Zajcev Evgeny]

Andreas Schwab <schwab@suse.de> writes:

> Zajcev Evgeny <zevlg@yandex.ru> writes:
>
>> Most of functions that deal with faces should use `(facep (get-face
>> <face>))' sexp to check face validity.
>
> Why do you need facep if get-face already did all validation?
>

Oh yes, it should be one of: `(get-face <face>)' or
`(facep (find-face <face>))' to avoid signals.

-- 
lg

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

[Stephen J. Turnbull]

>>>>> "Zajcev" == Zajcev Evgeny <zevlg@yandex.ru> writes:

    Zajcev> Andreas Schwab <schwab@suse.de> writes:

    >> Zajcev Evgeny <zevlg@yandex.ru> writes:

    >>> Most of functions that deal with faces should use `(facep
    >>> (get-face <face>))' sexp to check face validity.

    >> Why do you need facep if get-face already did all validation?

XEmacs doesn't need facep.  facep is useful in very few contexts, and
this isn't one of them.

    Zajcev> Oh yes, it should be one of: `(get-face <face>)' or
    Zajcev> `(facep (find-face <face>))' to avoid signals.

In XEmacs (facep (find-face ...)) is redundant.  It merely turns a
useful value (a face, which is just as true as t) into t.

There's no theoretical reason why would we couldn't sync to the Emacs
API, with faces being symbols registered as faces, no more and no
less.  However, in practice verifying it does no harm would be a lot
of work, and I don't see a benefit to it.  OTOH, adding the find-face
API to Emacs is trivial and can't do harm to existing code, although
it's really not necessary at all in Emacs AFAICS.  It's a minor
convenience in the code the OP posted, of course, but you could just
as easily inline Miles's implementation.

I don't see need for further discussion of XEmacs APIs on emacs-devel,
and I know y'all are quite busy right now.  So this is my last post in
this thread to emacs-devel (although I will continue to monitor it).
I will respond to further posts as appropriate, but (unless requested)
only on xemacs-beta.

Regards,

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

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

[Stefan Monnier]

> The thing is that XEmacsen `facep' returns non-nil only on face
> objects, not on their names or anything else, however `get-face' does
> all tricks - it returns face object getting face object or face name
> or anything else as input.  Here is:

My question was not "how do I do it with XEmacs".
It was "why does XEmacs do it this way".

The `foo-bar-p' runtime-type-check predicates like `commandp',
`functionp', `keymapp', `facep', `markerp', `stringp', `hash-table-p',
`char-table-p' are traditionally linked to the functions that operate on
them such that:
- (functionp foo) is non-nil iff you can pass `foo' to `funcall'.
- (commandp foo) is non-nil iff you can pass `foo' to `command-execute'.
- (keymapp foo) is non-nil iff you can pass it to `lookp-key'.
...

I'd thus expect that (facep foo) should return non-nil iff foo can be passed
to set-face-<bar> and similar functions.


        Stefan

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

[Stephen J. Turnbull]

>>>>> "Stefan" == Stefan  <monnier@iro.umontreal.ca> writes:

    >> A C structure wrapped in Lisp housekeeping information that
    >> implements a face.  I'm not sure why they were exposed to Lisp
    >> in the first place; I suspect to avoid repeated lookups in code
    >> that compares faces to determine if they contrast and the like.
    >> Probably a premature optimization.

    Stefan> I doubt the motivation was optimization.  I think it had
    Stefan> more to do with philosophical convictions.

Could be.  Might also be the issue of anonymous faces; at the time we
didn't have weak structures, so there was no easy way to guarantee it
would get GC'd in a timely fashion.

    >> A face name is a symbol.  A face object is a data structure.

    Stefan> I still don't understand why (facep 'foo) returns nil,
[...]
    Stefan> Just like (progn (fset 'foobar (make-keymap)) (keymapp
    Stefan> 'foobar)) return t rather than nil.

And so does (progn (fset 'foobar (make-keymap)) (fboundp 'foobar)), of
course.  But (progn (fset 'foobar (make-keymap)) (foobar)) errors, of
course.  Hardly convincing!

Anway, "that's different".  The symbol foobar is not a key in a table
somewhere, it _is_ the keymap in a physical sense.

I don't remember if Emacs has special object types for charsets and
coding systems, which are also named by symbols.  However, in XEmacs
the APIs all work the same way; type predicates return t for the object
but nil for the name, and have find-<type> and get-<type> interfaces.

Whether any of this really makes sense, I don't know, but it's consistent.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

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

[Stefan]

> And so does (progn (fset 'foobar (make-keymap)) (fboundp 'foobar)), of
> course.  But (progn (fset 'foobar (make-keymap)) (foobar)) errors, of
> course.

Of course.  `fboundp' doesn't test the type, only the boundness.
You want to try with `functionp'.


        Stefan

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

[Stephen J. Turnbull]

>>>>> "Stefan" == Stefan  <monnier@iro.umontreal.ca> writes:

    >> And so does (progn (fset 'foobar (make-keymap)) (fboundp
    >> 'foobar)), of course.  But (progn (fset 'foobar (make-keymap))
    >> (foobar)) errors, of course.

    Stefan> Of course.  `fboundp' doesn't test the type, only the
    Stefan> boundness.  You want to try with `functionp'.

You're right.  However, I found what's been worrying me:

(let ((name 'default)
      (object (find-face 'default)))
  (put name 'type 'name)
  (put object 'type 'object)
  (eq (get name 'type) (get object 'type)))

evaluates to nil in XEmacs, while

(let ((object (find-face 'default)))
  (put object 'type 'object)
  (eq (get object 'type) (face-property 'default 'type)))

evaluates to t.  I suppose you might consider that an abomination, and
of course neither of the exprs above makes sense in Emacs.  I guess we
could get rid of this "feature"; it's not portable so it probably
doesn't get used very much.

Currently, there are several types in XEmacs which can have properties
added or queried with put/get:

`get' is a built-in function
(get OBJECT PROPERTY &optional DEFAULT)

Documentation:
Return the value of OBJECT's PROPERTY property.
This is the last VALUE stored with `(put OBJECT PROPERTY VALUE)'.
If there is no such property, return optional third arg DEFAULT
(which defaults to `nil').  OBJECT can be a symbol, string, extent,
face, or glyph.  See also `put', `remprop', and `object-plist'.


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.