Re: Question

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Apr 11, 10:13am, Sven Wischnowsky wrote:
} Subject: Re: Question
} 
} Oh my, and I only asked if it would be better to mention the number of 
} lines needed for the list when asking if it should be displayed... ;-)

Like Andrej, I think it makes only a very small difference either way.

I was going to reply to a lot more of the remarks in this thread, but I
think it comes down to:  I don't think we should be "in the business" of
implementing pagers, but some alternate ideas come to mind ...

In a later message, Sven went on:
} 
} Err, wait. You almost certainly want to use different commands for
} different lists, so we would have to read the command line to use for
} piping first. Isn't that getting a bit too complicated?
} 
} Hm, make isearch work in menu-selection and the (proposed,
} vapour-warish) pager? Ouch.

Here are two possible suggestions; I haven't actually attempted either
of them.

(1)  Format up the completion listing as if it were going to shout, but
stuff it all into a string instead.  (That's probably happening already,
I didn't look.)  Then point a parameter at that string and invoke vared.
ZLE already takes care of paging up and down.

With some diddling of key-bindings, you can move around on the current
"screen" just as in menu-selection and arrange to exit from vared with
the parameter set to the substring the cursor was over when accept-line
was pressed.

(2) Use a "select x in ..." loop over the values.  As of some while ago,
select already knows how to page through screenfuls of choices.  You
can't go backwards, but it cycles to the top after reaching the bottom.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com