emacs-devel
[Top][All Lists]
Advanced

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

Re: widgets with dynamic-choice


From: Stefan Monnier
Subject: Re: widgets with dynamic-choice
Date: Tue, 19 Jul 2016 10:25:26 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

> 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




reply via email to

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