[Top][All Lists]

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

Re: Community improvements to the Emacs Widget Library manual?

From: Bryce
Subject: Re: Community improvements to the Emacs Widget Library manual?
Date: Wed, 12 Jul 2023 01:21:17 -0600

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Bryce <bovine@cyberscientist.ca> writes:
>> > What keyword handling do you mean, exactly (example)? I ask because
>> > AFAIR, `widget-create' works fine for user-defined widget types.
>> Writing :widget-create functions works, but there are no examples in the
>> manual.
> I meant `widget-create', not :widget-create.

Okay. I have not tried to insert one of my own widgets into a plain
buffer since I began properly defining one, but the argument
initialization code should indeed work to the same effect and if you can
define a widget, you can create it at point with `widget-create'. I'll
try this some time soon as a sanity check, however.

I am tired, it is also late here. I did manage to catch myself, and what
I've been talking about is the function value for the :create keyword. I
have been calling it :widget-create mistakenly. Pardon the confusion.

>> Perhaps a new macro should be introduced into the library which
>> facilitates accessing the nth argument _past the keyword-argument value
>> pairs_ in a reproducible way. The function widget-convert loops over the
>> arguments, assessing if they are keywords and makes them part of the
>> value of the :args property of the widget being created (if it is using
>> the default widget-convert functionality).
> But normally it should also set all of the given keywords - in this
> part:
>     ;; Finally set the keyword args.
>     (while keys
>       (let ((next (nth 0 keys)))
>       (if (keywordp next)
>           (progn
>             (widget-put widget next (nth 1 keys))
>             (setq keys (nthcdr 2 keys)))
>         (setq keys nil))))

Yes, for all arguments given to `create' after TYPE, they are
used to initialize values of properties (including user-defined

> After creating a widget with `widget-create' I expect that all
> keywords are set and can be referred to using `widget-get'.  The code
> above seems to fail when the arguments don't start with a keyword.
> Maybe this is not appropriate.

It should fail, but it should be refactored to provide an error message.
When an argument is not a keyword or the value corresponding to that
keyword (the loop iterates over pairs) it _must_ be handled "in a
widget-specific way." This is what should be improved in the library.

> AFAIR there are some bugs hiding in the code.  We must be careful not to
> document bugs and unintended behavior.  Not sure in this case (it's late
> here), but what I understand from what you are describing doesn't
> sound like desirable behavior.

I hope I've cleared up the confusion, but if I haven't, here's an
example of what I'm really trying to get at. It isn't valid syntax and
won't run, but the point is to /consume/ non-keyword arguments to
`widget-create' in a widget-specific way (for property initialization or

    | (define-widget 'matchbox 'checkbox
    |   "A cousin-level radiobutton, styled as a checkbox.
    | The BNF for this widget is:
    |     matchbox := (matchbox VALUE)
    |              | matchbox
    | VALUE is used to initialize :value.
    | It operates like a radio-button, but at the cousin-level (however
    | removed) rather than the sibling-level."
    |   :value nil
    |   :create
    |   (lambda (widget-type)
    |     (let (value)
    |       (widget-create 'checkbox :value value))))

Granted, the manual doesn't explicity advertise this functionality (see
next quote; either no arguments, one keyword-argument pair, or multiple
keyword-argument pairs), but it feels implied by writing elsewhere in
the manual.

    | -- Function: widget-create type [ keyword argument ]...

reply via email to

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