From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1380 invoked from network); 8 Sep 2009 23:39:58 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from new-brage.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.254.104) by ns1.primenet.com.au with SMTP; 8 Sep 2009 23:39:58 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 47664 invoked from network); 8 Sep 2009 23:39:50 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 8 Sep 2009 23:39:50 -0000 Received: (qmail 24205 invoked by alias); 8 Sep 2009 23:39:44 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 27252 Received: (qmail 24181 invoked from network); 8 Sep 2009 23:39:43 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 8 Sep 2009 23:39:43 -0000 Received: from QMTA12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by bifrost.dotsrc.org (Postfix) with ESMTP id 1B32D8026E39 for ; Wed, 9 Sep 2009 01:39:23 +0200 (CEST) Received: from OMTA18.westchester.pa.mail.comcast.net ([76.96.62.90]) by QMTA12.westchester.pa.mail.comcast.net with comcast id eJA31c0011wpRvQ5CPfPK0; Tue, 08 Sep 2009 23:39:23 +0000 Received: from smtp.klanderman.net ([98.217.254.247]) by OMTA18.westchester.pa.mail.comcast.net with comcast id ePj51c00S5M2Np63ePj6p3; Tue, 08 Sep 2009 23:43:06 +0000 Received: from lwm.klanderman.net (unknown [192.168.100.50]) by smtp.klanderman.net (Postfix) with ESMTP id 1C087B3015C; Tue, 8 Sep 2009 19:39:22 -0400 (EDT) Received: by lwm.klanderman.net (Postfix, from userid 500) id F12519FC5F3; Tue, 8 Sep 2009 19:39:21 -0400 (EDT) From: Greg Klanderman To: zsh-workers@sunsite.dk Subject: Re: need help with enhancement to prevent completion from stat'ing automounts Reply-To: gak@klanderman.net Date: Tue, 08 Sep 2009 19:39:21 -0400 In-Reply-To: <20090908111200.57cadc7c@news01> (Peter Stephenson's message of "Tue, 8 Sep 2009 11:12:00 +0100") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.17 (linux) References: <19106.55413.238410.101865@gargle.gargle.HOWL> <20090908111200.57cadc7c@news01> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.94.2/9785/Tue Sep 8 17:36:59 2009 on bifrost X-Virus-Status: Clean Hi Peter, thank you for having a look at this.. I'm quite certain that passing the 'fake' files and directories to compadd would solve the problem here. I will acknowledge that IMO the most correct change would be to introduce a 'fake-dirs' zstyle and fix all of _path_files and compfiles to maintain these fake completions separately so they can be given to compadd with the correct suffix rather than '-f' when the time comes. But I find those two pieces of code so impenetrable that I'm having trouble forcing myself down that path. And so another idea is to add an array parameter, say completion_automount_roots, which I could maybe set to (/net /home) and have bound to a C variable, then in the ztat() function return 'directory' without stat()ing any files directly under those roots. Not pretty, but I can see exactly what needs to be done and it's not too hard. I'll comment on a few bits or your reply below.. >>>>> On September 8, 2009 Peter Stephenson wrote: > It's fairly easy to pass an array into C, particularly if it's going into > compfiles which is the accelerator for _path_files and so has its own > exclusive API, but if you really need to grope in compresult.c it's > trickier. I'm not sure what API you need to access; the core completion > system is heavily customized to make it possible to do clever things with > multiple sets of completions, so an array applying to all of them is > probably too gross. Right, though in this case it's pretty certain you don't want to stat all several hundred automounts no matter what the mechanism you got to that completion was. > Still, if the stat is that low down in the system > you've got problems. It should be possible to add an option to compadd > giving an array of special things and store that in an appropriate group of > results, parallel to the various other things that go into compadd. This > is all quite hairy. The difficulty is maintaining those three sets of completions all the way from the compfiles call to one of the compadd calls (whichever one you get to) in _path_files. Also you have to be a little careful - currently, it seems that compfiles is merging a 'fake-file' of the same name as a mounted automount which the normal completion finds. You only want the mounted automounts to appear in the completion list once, not twice. > Is your case fixed by not passing the "-f" to compadd? Then the problem is > limited to _path_files and compfiles, which should be easier to trace. "Easier" .. ha ha! > Separating fake and real files into different compadd calls should be > possible (you're now using to advantage the facility for multiple matches > that I just explained above makes it harder to change the low level stuff). In theory, I agree. > There's a problem that if you're not statting the file you've completed you > obviously don't know if it's a directory, so if you complete /home/u to > /home/user you don't get the slash. Maybe (part of) the solution is a > fake-dirs style, for stuff that is added in as directory, i.e. with a / > suffix, but without the -f argument to compadd? That still needs code in > _path_files but possibly not elsewhere Yes of course you need to tell it to use '/'. > (I'm not clear what you need to do with compfiles here). the fake-files are passed into compfiles, and by the time it returns, all memory of what's fake and what's not has been lost. > I haven't seen an easier way around your original problem---unnecessarily > accessing files can be quite a big problem particular on some systems > (Cygwin in my case) so a fairly general solution to this would certainly be > a good thing. Accessing lots of files seems fine, it's accessing hundreds of automounts many of which are no longer valid here at work and take 60 sec each to time out that it's really a problem.. thanks, Greg