Re: widgets with dynamic-choice

[Ted Zlatanov <tzz@lifelogs.com>]

On Tue, 19 Jul 2016 09:24:15 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>>>> * when should the widget get updated?
SM> [ BTW, "updated" doesn't seem like the right word.  Did you mean
SM>   "computed"?  ]

Yes, thank you.

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?

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

I think that's easy for the programmers but annoying for the users.
Responsive UI is important everywhere in Emacs. I am happy to discuss
the pros and cons of what I'm proposing, I'm not saying it must be done.
Only that it should not be discarded outright.

Specifically for this case, interactive dialogs should show something
within 1-5 seconds or users will assume something is wrong and try to
interrupt or move away. The research below is on website responsiveness,
but IMO also applies to us:

https://www.nngroup.com/articles/website-response-times/

>>>> * 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...

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

Because currently widgets load instantly from a fixed set (with the one
exception you mentioned), and with this proposal they can call a
function. We're adding complexity so I wanted to at least consider the
effect of it to users in the Customize interface.

>> (defcustom myvar nil "Whatever" :type '(choice :dynamic myvar-dynamic-choice-function))

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

All right, if we agree on the handling of errors and timeouts (none for
now), and on the defcustom syntax above, here's my implementation proposal:

I think `widget-setup' is the right place to add the dynamic fills
(computation), hooking that into the buffer redisplay hook. The part of
`widget-*-value-create' that gets and inserts the list of choices from
:args will need to be factored out so it can be called from
that hook. WDYT?

Ted