completion within word

completion within word

[Matthias B.]

What do I have to do to get

PATH=$PATH:/bi<TAB>

to complete the "/bi" to /bin"

and

svn file:///ho<TAB>

to complete the /ho to /home ?

I've read the options chapter in the zsh manual front to back and back to
front but can't find anything.
This works in bash and I find the lack of this feature very painful.

MSB

-- 
Life is the ultimate cynic.

Re: completion within word

[Thomas Köhler]

[-- Attachment #1: Type: text/plain, Size: 1244 bytes --]

Matthias B. wrote:
> What do I have to do to get
> 
> PATH=$PATH:/bi<TAB>
> 
> to complete the "/bi" to /bin"

Add this to your .zshrc:
autoload -U compinit
compinit

You can also run compinstall which lets you configure lots of
completion options on its way and adds a few lines to your .zshrc
then. I recommend this :-)

> and
> 
> svn file:///ho<TAB>
> 
> to complete the /ho to /home ?

Uhm. Seems there is no completion for svn as of yet (for zsh
4.0.6 which I still run here). Is there one for zsh 4.2? Anybody?

> I've read the options chapter in the zsh manual front to back and back to
> front but can't find anything.
> This works in bash and I find the lack of this feature very painful.

You can use bash completion functions in zsh beginning with
version 4.2, so just add the completion for svn to zsh's
completion functions (and make sure your zsh is recent enough).
Should help if there is no zsh native function...

> MSB

Ciao,
Thomas

-- 
 Thomas Köhler       Email:       jean-luc@picard.franken.de
     <><             WWW:              http://gott-gehabt.de
                     IRC:                           tkoehler
                     PGP public key available from Homepage!

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: completion within word

[Peter Stephenson]

Thomas =?iso-8859-1?Q?K=F6hler?= wrote:
> Uhm. Seems there is no completion for svn as of yet (for zsh
> 4.0.6 which I still run here). Is there one for zsh 4.2? Anybody?

Yes, it's present in 4.2.  The completion in question works.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: completion within word

[Matthias B.]

On Wed, 22 Sep 2004 06:55:11 +0200 Thomas Köhler
<jean-luc@picard.franken.de> wrote:

> Matthias B. wrote:
> > What do I have to do to get
> > 
> > PATH=$PATH:/bi<TAB>
> > 
> > to complete the "/bi" to /bin"
> 
> Add this to your .zshrc:
> autoload -U compinit
> compinit

Okay, I've tried it for a while and I'm not happy with it. I have the same
problems with it as with the bash programmable completion project. Little
annoyances everywhere such as "svn import k<TAB>" refusing to complete on
files in the current directory and there's also the complexity. I feel
uneasy about using the completion code as root, because it touches lots of
files behind my back.

So I'm going to live with basic builtin completion. Any chances of getting
the above completion to work with it? If not, I'd be grateful for pointers
into the zsh code so that I can see if I can fix it myself. 

MSB

-- 
The real art of conversation
is not only to say the right thing at the right time,
but also to leave unsaid the wrong thing at the tempting moment.

Re: completion within word

[Oliver Kiddle]

On 25 Sep, "Matthias B." wrote:

> Okay, I've tried it for a while and I'm not happy with it. I have the same
> problems with it as with the bash programmable completion project. Little
> annoyances everywhere such as "svn import k<TAB>" refusing to complete on
> files in the current directory and there's also the complexity. I feel

The patch below fixes that particular annoyance. If you let us know
about any other little annoyances, we can either fix them or let you
know how to configure zsh to avoid them. I've tended to believe that we
have fewer half-hearted attempts at completion functions than
bash_completion.

> So I'm going to live with basic builtin completion. Any chances of getting
> the above completion to work with it? If not, I'd be grateful for pointers
> into the zsh code so that I can see if I can fix it myself. 

I'm not entirely sure how to fix that from the builtin completion using
only compctl. I've not used it in a while. It would be possible using a
standalone completion widget function which specifically looks for that
situation. I'd suggest you just try to use the $path array form of $PATH
instead because it is easier to manipulate. Instead of the your line,
you can do:

  path=( $path /bi<tab>
or in zsh 4.2:
  path+=( /bi<tab>

Oliver

Index: Completion/Unix/Command/_subversion
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Command/_subversion,v
retrieving revision 1.6
diff -u -r1.6 _subversion
--- Completion/Unix/Command/_subversion	14 Apr 2004 08:17:53 -0000	1.6
+++ Completion/Unix/Command/_subversion	27 Sep 2004 09:10:21 -0000
@@ -84,7 +84,7 @@
     ;;
     *)
       case $_svn_subcmd_usage in
-        *(SRC|DST|TARGET|URL*PATH)*)
+        *(SRC|DST|TARGET|URL*PATH|PATH*URL)*)
           _svn_subcmds+=( 
 	    '*: : _alternative "files:file:_files" "urls:URL:_svn_urls"'
 	  )

Re: completion within word

[Matthias B.]

On Mon, 27 Sep 2004 11:19:51 +0200 Oliver Kiddle <okiddle@yahoo.co.uk>
wrote:

> On 25 Sep, "Matthias B." wrote:
> 
> > Okay, I've tried it for a while and I'm not happy with it. I have the
> > same problems with it as with the bash programmable completion
> > project. Little annoyances everywhere such as "svn import k<TAB>"
> > refusing to complete on files in the current directory and there's
> > also the complexity. I feel
> 
> The patch below fixes that particular annoyance. If you let us know
> about any other little annoyances, 

Well, here's another one:

man  /us<TAB>

refuses to complete /usr. Same for

cvs import /us<TAB>

How can you guys live with a system that completely breaks basic path
completion? Over 99% of the time I want to complete paths, but seemingly
the completion code was written just for the remaining 1%. Are my work
patterns so different from everybody else's?

>we can either fix them or let you
> know how to configure zsh to avoid them.

Thanks for the offer, but I just don't have the patience to play
beta-tester for the completion code, which would probably require dozens
of fixes just to make sure I don't trip over a problem every couple days.
Every instance of a non-working completion is a major annoyance for me.
I've seen it with bash_completion and I see it again with zsh's completion
that for me the benefits simply do not outweigh the annoyances.

> I've tended to believe that we
> have fewer half-hearted attempts at completion functions than
> bash_completion.

My problem with bash completion was not half-hearted completion attempts,
it was the fact that whenever a specific completion existed for a command,
basic path completion for it seemed to be broken. zsh's code seems to
suffer from the same problem. 

And this seems to be not just an issue of a few bugs. It appears to be a
conscious and major design decision for both projects, a design decision
that is incompatible with my work habits.

As I see it, bash_completion and zsh's completion get it all backwards.
They offer pathname completion only as a fallback and do even that only
when the completion code believes that a pathname makes sense in the
appropriate position. I'd like a completion system that works the other
way around. Pathname completion should *always* work *unconditionally* and
everything else should be offered in addition to it, if the completion
code believes it makes sense in the appropriate position. Under  *NO*
circumstances should the completion code refuse to complete a path, just
because it believes (always erroneously!) that I'm trying to do something
stupid.


But even if the completion system worked the way I want it to, there would
still be the complexity argument. It just makes me feel uneasy if just
pressing <TAB> touches who-knows-what files and calls who-knows-what
commands. 

> > So I'm going to live with basic builtin completion. Any chances of
> > getting the above completion to work with it? If not, I'd be grateful
> > for pointers into the zsh code so that I can see if I can fix it
> > myself. 
> 
> I'm not entirely sure how to fix that from the builtin completion using
> only compctl. 

As I said, pointers into the zsh code (I mean the C source code) are fine
with me. When I press <TAB> and nothing happens in a situation where bash
offers me something useful, that's a bug in zsh that needs to be fixed in
the source.

> situation. I'd suggest you just try to use the $path array form of $PATH
> instead because it is easier to manipulate. Instead of the your line,
> you can do:
> 
>   path=( $path /bi<tab>
> or in zsh 4.2:
>   path+=( /bi<tab>

I know, but this doesn't help me. I actually encountered this problem with
a different variable and only used PATH as an example. Besides, as you've
probably noticed already I'm not the kind of person who'll just retrain
himself to work around shortcomings of a program. If a program doesn't do
what I want, the program has to change. The user is always right! :-)

MSB 

-- 
A man without light need not fear darkness.

Re: completion within word

[Peter Stephenson]

"Matthias B." wrote:
> Pathname completion should *always* work *unconditionally* and
> everything else should be offered in addition to it, if the completion
> code believes it makes sense in the appropriate position.

That would be completely unworkable for the vast majority of special
contextual completions.  You can bind a key that just does filename
completion, however.  This binds it to \C-f.  Oliver may know some
gotchas I'm missing.

zle -C complete-filename complete-word _generic
zstyle ':completion:complete-filename:*' completer _files
bindkey '^xf' complete-filename 

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: completion within word

[Matthias B.]

On Mon, 27 Sep 2004 15:18:49 +0100 Peter Stephenson <pws@csr.com> wrote:

> "Matthias B." wrote:
> > Pathname completion should *always* work *unconditionally* and
> > everything else should be offered in addition to it, if the completion
> > code believes it makes sense in the appropriate position.
> 
> That would be completely unworkable for the vast majority of special
> contextual completions.  

As I've said, I am aware that the root of my problems seems to be a design
decision incompatible with my work habits.

> You can bind a key that just does filename
> completion, however.  This binds it to \C-f.  

You mean ^X F, don't you?

> Oliver may know some
> gotchas I'm missing.

I can tell you. It doesn't solve my original problem, which is that

BLA=/usr:/us<COMPLETE>

doesn't complete the /us after the ":". Your file-completion doesn't do
that either. bash does, though and I've grown used to this feature and
don't want to miss it.

MSB

-- 
Black holes are where God divided by zero.

Re: completion within word

[Peter Stephenson]

"Matthias B." wrote:
> You mean ^X F, don't you?

Sorry, yes.

> 
> > Oliver may know some
> > gotchas I'm missing.
> 
> I can tell you. It doesn't solve my original problem, which is that
> 
> BLA=/usr:/us<COMPLETE>
> 
> doesn't complete the /us after the ":".

But that *does* definitely work with the basic completion system.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: completion within word

[Oliver Kiddle]

"Matthias B." wrote:
> On Mon, 27 Sep 2004 15:18:49 +0100 Peter Stephenson <pws@csr.com> wrote:
> 
> > "Matthias B." wrote:
> > > Pathname completion should *always* work *unconditionally* and
> > > everything else should be offered in addition to it, if the completion
> > > code believes it makes sense in the appropriate position.

Use _files as a completer. If you use a wrapper around _files, you can
make it return 1 causing later completers to get a go after it:

_files_first() {
  _files "$@"
  return 1
}
zstyle ':completion:*::::' completer _files_first _complete _ignored

It'll now always give you file completion. To solve the PATH colons
problems, add the compset commands in my later example.

> > You can bind a key that just does filename

> > Oliver may know some gotchas I'm missing.

Only that I'd use ':completion:complete-filename::::' as the context.

Also note that you can simply use:
  bindkey '\ef' _bash_complete-word

> I can tell you. It doesn't solve my original problem, which is that
> 
> BLA=/usr:/us<COMPLETE>

You can create a wrapper around _files to handle the colons:

_my_files() {
  compset -P '*:'
  compset -S ':*'
  _files "$@"
}

Oliver

Re: completion within word

[Joel David Elkins]

Isn't the colon-variable completion problem simply solved by
redefining what a "word" is with something like select-word-style? The
sledge hammer approach is to define words just as bash does with the
following. There are more subtle ways to just exclude : from the list
of word characters; such methods are adequately documented in the
manual. Of course, this approach has other (IMO consistent therefore
desirable) effects besides completion, such as ^W behavior.

autoload -U select-word-style
select-word-style bash

$ BLA=/foo:/us<TAB>
$ BLA=/foo:/usr/

On Mon, Sep 27, 2004 at 05:12:24PM +0200, Oliver Kiddle wrote:
> Also note that you can simply use:
>   bindkey '^[f' _bash_complete-word
> 
> > I can tell you. It doesn't solve my original problem, which is that
> > 
> > BLA=/usr:/us<COMPLETE>
> 
> You can create a wrapper around _files to handle the colons:
> 
> _my_files() {
>   compset -P '*:'
>   compset -S ':*'
>   _files "$@"
> }
> 
> Oliver
> 

-- 
Joel Elkins <jde@elkins.cx>