Re: need help with enhancement to prevent completion from stat'ing automounts

[Greg Klanderman <gak@xxxxxxxxxxxxxx>]

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 <pws@xxxxxxx> 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