From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10857 invoked from network); 6 Jan 2000 09:45:21 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 6 Jan 2000 09:45:21 -0000 Received: (qmail 18804 invoked by alias); 6 Jan 2000 09:45:16 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9238 Received: (qmail 18797 invoked from network); 6 Jan 2000 09:45:16 -0000 Date: Thu, 6 Jan 2000 10:45:15 +0100 (MET) Message-Id: <200001060945.KAA13577@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Andrej Borsenkow"'s message of Thu, 6 Jan 2000 10:32:54 +0300 Subject: Re: mapfile module - avoiding $(...) in completion functions Andrej Borsenkow wrote: > > Since in the completion system we generally want to avoid the extra > > processes needed for $(...), we would use caching for the printer > > names there (and the function for the lp commands I just sent to > > zsh-workers does that). And we would also make this nicer by > > supporting the other mechanisms used throughout the completion system. > > > > May be it was discussed already, but is not mapfile module alternative to > $(...)? We mostly need it to parse files content, as in $( in this case we could just as well mmap the file. > > ... > > Is there any system now-a-days without mmap support? I'd like to know that, too. It's the reason why I haven't used mapfile in completion functions yet. > And where the "real" $(...) is needed, we cannot cache it anyway (process list > is an example). And fonts, X-extensions, tar and YP-stuff are counterexamples. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de