zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <pws@csr.com>
To: zsh-workers@sunsite.dk
Subject: Re: need help with enhancement to prevent completion from stat'ing automounts
Date: Tue, 8 Sep 2009 11:12:00 +0100	[thread overview]
Message-ID: <20090908111200.57cadc7c@news01> (raw)
In-Reply-To: <m3bplmnpwv.fsf@klanderman.net>

On Mon, 07 Sep 2009 22:14:40 -0400
Greg Klanderman <gak@klanderman.net> wrote:
> >>>>> Greg Klanderman <gak@klanderman.net> writes:
> 
> > Now I just need some help to figure out what a reasonable way to
> > create a general configuration to support this would be.
> 
> So it looks like a zstyle would not work, because I need to access the
> configuration from C.  Seems like the only real option is to create an
> array parameter - does that make sense?

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

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

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 (I'm not clear what you need to do
with compfiles here).

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.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom


  reply	other threads:[~2009-09-08 10:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-05 21:30 Greg Klanderman
2009-09-08  2:14 ` Greg Klanderman
2009-09-08 10:12   ` Peter Stephenson [this message]
2009-09-08 23:39     ` Greg Klanderman
2009-09-10  9:30       ` Peter Stephenson
2009-09-10 14:52         ` Greg Klanderman
2009-11-24 16:07           ` Greg Klanderman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090908111200.57cadc7c@news01 \
    --to=pws@csr.com \
    --cc=zsh-workers@sunsite.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).