From: Borzenkov Andrey <Andrey.Borzenkov@siemens.com>
To: "'Phil Pennock'" <phil.pennock@globnix.org>, zsh-users@sunsite.dk
Subject: RE: Completion of dirs confused over cursor position
Date: Thu, 9 Jan 2003 19:01:50 +0300 [thread overview]
Message-ID: <6134254DE87BD411908B00A0C99B044F03A0B5D2@MOWD019A> (raw)
In-Reply-To: <20030109160645.GA22637@globnix.org>
> On 2003-01-09 at 18:02 +0300, Borzenkov Andrey wrote:
> > function _foo {
> > _files -W /some/directory
> > }
> > compadd _foo commandname
> >
> > does it work?
>
> No:
> compadd: can only be called from completion function
>
compdef. Shame on me :(
bor@itsrm2% compdef _foo foo
bor@itsrm2% function _foo { _files -W ~/test }
bor@itsrm2% foo a\ b/
Completing file
a\ b/ c\\\ d/ radius/ uudecode/
> However, that's looking much simpler than anything in the manual pages
> or the examples I looked at in the distributed completions. :^) I was
> getting lost in functions calling functions calling functions
> maintaining various levels of state, with reference man-pages and no
> tutorial.
>
> Is there a tutorial somewhere which I've missed?
http://zsh.sunsite.dk/Guide/
The manual pages are
> some of the most daunting I've seen. I do read manual-pages, but
> looking at these I can't get a mental handle on the frameword and what
> fits where, to get started.
>
what we need is splitting current documentation into development guide and
user stuff. Completion manual pages are more of the former but they lack too
much to be of any real use. And average user needs mostly just _arguments,
_files and possibly _values to generate own completions and exactly these
have to poor documentation (and nightmare syntax :)).
-andrej
> > And doing it automatically:
> >
> > echo > ~/functions/_foo << EOF
> > #compadd commandname
> > _files -W /some/directory
> > EOF
>
> That general structure I had (although I suspect that you meant cat,
> since echo doesn't use its stdin).
Urgh :))
And the supplied versions use
> "#compdef". If I use "#compadd", it's not auto-loaded.
>
> > fpath=($fpath ~/functions)
> > compinit
>
> And that I had.
>
> > the last part obviously goes into .zshrc or whatever. Try running
> > compinstall as well.
>
> Yup, tried that.
>
> Okay, logging in again, forcing a rebuild of .zcompdump (after changing
> to "#compdef", it now works. :^)
>
> Thanks,
>
> -Phil
next prev parent reply other threads:[~2003-01-09 16:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-08 19:46 Phil Pennock
2003-01-09 10:42 ` Peter Stephenson
2003-01-09 14:51 ` Phil Pennock
2003-01-09 15:02 ` Borzenkov Andrey
2003-01-09 16:06 ` Phil Pennock
2003-01-09 16:01 ` Borzenkov Andrey [this message]
2003-01-09 18:35 ` Bart Schaefer
2003-01-10 13:58 ` Phil Pennock
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=6134254DE87BD411908B00A0C99B044F03A0B5D2@MOWD019A \
--to=andrey.borzenkov@siemens.com \
--cc=phil.pennock@globnix.org \
--cc=zsh-users@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).