widgets with dynamic-choice

widgets with dynamic-choice

[Ted Zlatanov]

I've needed widgets with dynamic choices many times for Customize.
Stefan also suggested a `dynamic-choice' would be handy. So, I wanted to
ask some questions before we write code:

* what should it look like? Just a callable symbol or a form or
  something else?

* when should the widget get updated?

* how do we deal with outliers like a dynamic 100000 element list?

* how are errors handled? do we empty the list or go back to the last
  good version?

* should this just be a way to provide 'choice and 'radio, or do we want
  a more generic facility that can handle the other composite types?

Ted

Re: widgets with dynamic-choice

[Stefan Monnier]

> * what should it look like? Just a callable symbol or a form or
>   something else?

As you may know I abhor `eval`, so I'd rather not have a "form" there,
but a function instead.

> * when should the widget get updated?

When we need to display it?

> * how do we deal with outliers like a dynamic 100000 element list?

The widget probably shouldn't try to do anything special for that.
The same problem already exists with `choice` after all.

> * how are errors handled? do we empty the list or go back to the last
>   good version?

I wouldn't try to be clever here either.  Just let the signal percolate.

> * should this just be a way to provide 'choice and 'radio, or do we want
>   a more generic facility that can handle the other composite types?

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


        Stefan

Re: widgets with dynamic-choice

[Ted Zlatanov]

On Mon, 18 Jul 2016 13:26:44 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> * what should it look like? Just a callable symbol or a form or
>> something else?

SM> As you may know I abhor `eval`, so I'd rather not have a "form" there,
SM> but a function instead.

I didn't know that, but OK :)

>> * when should the widget get updated?

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?

>> * how do we deal with outliers like a dynamic 100000 element list?

SM> The widget probably shouldn't try to do anything special for that.
SM> The same problem already exists with `choice` after all.

OK.

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

>> * should this just be a way to provide 'choice and 'radio, or do we want
>> a more generic facility that can handle the other composite types?

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.

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))

Ted

Re: widgets with dynamic-choice

[Stefan Monnier]

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

Re: widgets with dynamic-choice

[Ted Zlatanov]

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

Re: widgets with dynamic-choice

[Stefan Monnier]

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

Agreed, but if the function takes a month, what can the widget do?
Timeout and then what?  A "UI" which tells me "this thing
timed out" is not a "responsive UI".  A responsive UI will do something
*useful* in a timely fashion.

You could use an async interface, calling the function with a callback
so the display can be updated incrementally as new elements of the
dynamic choice are encountered.  Of course, that still doesn't solve the
case where the next element takes a month to be found.

"Too long computations" are simply bugs in the function and there's
no point trying to detect them in the widget code, IMO: the user will
notice the problem on its own anyway.

> Specifically for this case, interactive dialogs should show something
> within 1-5 seconds or users will assume something is wrong

And rightly so.

> and try to interrupt or move away.

So, not very different from what you'd get by adding a timeout.  Hence,
adding a timeout doesn't improve the user's experience.  To improve the
user's experience, you need to fix the underlying function so it doesn't
take that long.

BTW, for all the cases I remember where I've wanted a `dynamic-choice'
widget, the computation of the list would be trivial and instantaneous.

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.

Even loading from a fixed set, I've experienced bugs with the
customize UI.  This really is no different (and it's even less
different if you consider Emacs as a whole).

> 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?

The reason why I haven't implemented it myself is because I know next to
nothing about the widget code, so I'm afraid I won't be of much
help here.


        Stefan

Re: widgets with dynamic-choice

[Ted Zlatanov]

On Tue, 19 Jul 2016 10:25:26 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

> Ted wrote:
>> 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?

SM> The reason why I haven't implemented it myself is because I know next to
SM> nothing about the widget code, so I'm afraid I won't be of much
SM> help here.

That's some pretty old code, too. Do we really have no one knowledgeable
on this topic? I see some wid-edit.el changes from you, Nicolas Richard,
Chong Yidong, and Jan Djärv in the last 5 years. I would love to have
someone review the proposal even if it's a quick yes/no.

Ted