Re: widgets with dynamic-choice

[Stefan Monnier <monnier@iro.umontreal.ca>]

>>> * when should the widget get updated?

[ BTW, "updated" doesn't seem like the right word.  Did you mean
  "computed"?  ]

SM> When we need to display it?
> That means potentially a long delay on display. With customization UIs
> that can be really frustrating. Can we agree on a timeout at least?

We don't have such a thing for the completion table of text-based
widgets, so I don't see why we should have that here.  IOW I think it's
the responsability of the function not to take too much time.

>>> * how are errors handled? do we empty the list or go back to the last
>>> good version?
SM> I wouldn't try to be clever here either.  Just let the signal percolate.
> So presumably a novice user will get a strange error that they don't
> know how to handle or report? It's a practical solution but maybe a bit
> unfriendly...

In case there's a bug in the function?  Yes.  Same as when there's a bug
anywhere else.  I don't understand why you think this case is different.

SM> I think we should start with a dynamic version of `choice` and see from
SM> there if it can be easily generalized or not.

> OK, so this is the simple way:
>
> (defcustom myvar nil "Whatever"
>   :type '(dynamic-choice myvar-dynamic-choice-function))
>
> Simple and easy to understand, but not extensible.

Right.

> Could we leave room for future extension? The following will be a bit
> friendlier if other types are supported.
>
> (defcustom myvar nil "Whatever"
>   :type '(choice :dynamic myvar-dynamic-choice-function))

Yes, it would be great to allow this kind of :dynamic for
various types.  But I'm not familiar enough with the code to have
a sense of how it would work out.


        Stefan