Re: Question

[Sven Wischnowsky <wischnow@informatik.hu-berlin.de>]

Bart Schaefer wrote:

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

I agree that this sounds very interesting, but there are two things
I'm worried about:

The first one is a real problem that can't be avoided with this
solution: the colouring that's possible with complist would be lost. I 
guess you don't use it, but I at least have become quite fond of it. I 
especially like the look of a process listing in menu-selection with
the `cursor' in red, spanning the whole line. Much better `readable'
then the typical single-character cursor on a all black-on-white (grey 
for me) style vared could give us.

The second one is mostly a fear, I haven't fully checked: the
completion listing code is currently a bit like a separate system,
separated from the sorroundings, that is. I'm not sure what could
happen when we allow something like vared (with possible user defined
widgets being called) while the completion list is displayed.
Especially for menu-selection, I think. Maybe that isn't really a
problem, though. But it would also mean that the prompt wouldn't be
visible during a menu-selection.

And then: all the changes needed to build the string (which may also
get pretty large). Urgh.

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

I never liked select and fiddling with numbers in completion lists
seems weird to me. But then: `select already knows how to page' and `I
don't think we should be "in the business" of implementing pagers'.

If select does pages, why shouldn't the completion code do that,
too. There were times when they were implemented by the same function, 
almost.


I've played with implementing some of the stuff yesterday evening and
it's surprisingly small and menu-selection with scrolling looks funny.
Can't show you the patch yet, though, because it's incompatible with
the current CVS and there are some things missing/untested.

And never fear: I certainly won't commit the patch without showing it
to the list first.

A final thought: complist is intended as the module to allow fancy
completion list handling... would it be acceptable to add this
scrolling stuff only to it? Well, some basic functions would need to
be in the complete module...

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de