From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16880 invoked from network); 12 Apr 2000 08:52:09 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 12 Apr 2000 08:52:09 -0000 Received: (qmail 10105 invoked by alias); 12 Apr 2000 08:52:03 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10687 Received: (qmail 10090 invoked from network); 12 Apr 2000 08:52:02 -0000 Date: Wed, 12 Apr 2000 10:51:55 +0200 (MET DST) Message-Id: <200004120851.KAA07258@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Tue, 11 Apr 2000 15:45:16 +0000 Subject: Re: Question 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