zsh-users
 help / color / mirror / code / Atom feed
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


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