RE: A widget-based version of find-cmd

[Drew Adams]

> Yes, of course.  Another direction (complementary rather than opposed to
> what you're suggesting) would be to extend Elisp's completion so it
> understands `find-cmd` and hence gives you the valid completion after
> you type `(find-cmd '(pru TAB`

Yes, both would be useful additions.  Completion is
handy and quick.  On the other hand, it would be
good to be able to fill out a "dialog box" (widgets)
once, and have the same filled-out settings available
for subsequent reuse (until you change some of those
settings).

You can perhaps get somewhat the same advantage from
completion by using `M-p' to retrieve the last input
for each completion type (assuming they are on separate
minibuffer histories), but that's not quite as handy.

One of the advantages of a dialog box in such contexts
is setting it and reusing it for multiple search actions
(interspersed with other, non-search actions).  In fact,
that's about the only advantage I find for such a dialog
box.

In sum, when there are possibly a bunch of settings you
might fill out, Emacs should save them and offer them
to you again.  You should not need to fill out the same
choices multiple times consecutively.

> I'm sending you all my psychic power.  I hope it helps.

Ditto, FWIW.

> > What I basically need is to define a
> > widget type that let's you choose from a list of options.  Among them
> > are combiners like "or" that, when chosen, should provide a widget of
> > the same type.  My problem is that I run into an infinite recursion.  I
> > thought I can avoid that by constructing the widget deferred via
> > :convert-widget but that doesn't help.  Maybe :convert-widget is not for
> > that purpose (actually, then I don't get the purpose of :convert-widget
> > from the widget manual).
> 
> I think you're looking for the `lazy` widget.

Or maybe just split it up, having part of it use `repeat'?

Thanks for working on this, Michael.