Completion suggestions

Completion suggestions

[Oliver Kiddle]

On Feb 5, 11:31am, "Andrej Borsenkow" wrote:

> Thanks, Sven! The only question is, is it possible to make final comma to be
> autoremoved? Currently I get
> rm glib{-1.1.so.12,-1.1.so.12.0.0,

Completion in braces is something I've wanted for ages and I must have
missed the message with the patch but I've just noticed it now works
with the zsh I'm using - great, thanks.

Anyway, this has reminded me of another completion feature which I'd
like. When typing a filename as a parameter where the filename I want to
use contains a special character (such as a space), I obviously have to
use quoting of some sort. What would be nice is if the completion was
aware of quotes and assumed that I wasn't going to quote unnecessarily.

For example:
~ [56]% :> "a file"
~ [57]% :> afile
Currently:
~ [58]% vi "a<tab>
Lists:
a file   afile

I'd find it useful if it completed to the file with the space in it: I
wouldn't have bothered to type the '"' if I wanted to edit afile. This
will ofcourse need to be aware of \ quoting and the closing quote. I
wouldn't be suprised if some people wouldn't like this so if
implemented, it might need to be an option.

Another thing which would be quite useful is some way to specify if
files listed as parameters to a command should be unique. Taking the rm
example above, it would be pointless to type:

rm glib-1.1.so.12 glib-1.1.so.12

so rm glib{-1.1.so.12,<tab>
should not offer -1.1.so.12 but complete to anything else such as
-1.1.so.12.0.0

I've also just discovered the following possible bug which might have
been fixed since the version I've got here (3.1.5; maybe pws-3):

~ [67]% rm a{\ <tab>
Gives me:
~ [67]% rm a\ file,

Has any thought been given to implementing tcsh's complete=enhance
functionality. I found the `.', `-' and `_' handling occaisionally
useful and sometimes annoying. I liked the case-insensitivity aspect
however the ideal in my opinion would be for anything which I
explicitly type in uppercase to remain in uppercase but anything typed
in lowercase to be treated as completable to uppercase. If this tcsh
functionality does get implemented there should be separate options for
the two (very distinct in my opinion) features.

Thanks

Oliver Kiddle

Re: Completion suggestions

[Sven Wischnowsky]

Oliver Kiddle wrote:

> Anyway, this has reminded me of another completion feature which I'd
> like. When typing a filename as a parameter where the filename I want to
> use contains a special character (such as a space), I obviously have to
> use quoting of some sort. What would be nice is if the completion was
> aware of quotes and assumed that I wasn't going to quote unnecessarily.
> 
> For example:
> ~ [56]% :> "a file"
> ~ [57]% :> afile
> Currently:
> ~ [58]% vi "a<tab>
> Lists:
> a file   afile
> 
> I'd find it useful if it completed to the file with the space in it: I
> wouldn't have bothered to type the '"' if I wanted to edit afile. This
> will ofcourse need to be aware of \ quoting and the closing quote. I
> wouldn't be suprised if some people wouldn't like this so if
> implemented, it might need to be an option.

As an option, maybe. But if you have something like zsh -c "ls f<TAB>", 
you'll want all files.

> Another thing which would be quite useful is some way to specify if
> files listed as parameters to a command should be unique. Taking the rm
> example above, it would be pointless to type:
> 
> rm glib-1.1.so.12 glib-1.1.so.12
> 
> so rm glib{-1.1.so.12,<tab>
> should not offer -1.1.so.12 but complete to anything else such as
> -1.1.so.12.0.0

This is something I'd like to have, too. One thing I'm planning to do
is give a way to access/change/delete matches from those that were
generated in the new style completion stuff, with that it might become 
easier to do such things. You can already get this with a shell
function and the `-K' option, though, but only if used without brace
expansion (since the completion code currently doesn't see the other
strings in the braces).

> I've also just discovered the following possible bug which might have
> been fixed since the version I've got here (3.1.5; maybe pws-3):
> 
> ~ [67]% rm a{\ <tab>
> Gives me:
> ~ [67]% rm a\ file,

This is fixed since pws-<dunno>, at least 6 and 7.

> Has any thought been given to implementing tcsh's complete=enhance
> functionality. I found the `.', `-' and `_' handling occaisionally
> useful and sometimes annoying. I liked the case-insensitivity aspect
> however the ideal in my opinion would be for anything which I
> explicitly type in uppercase to remain in uppercase but anything typed
> in lowercase to be treated as completable to uppercase. If this tcsh
> functionality does get implemented there should be separate options for
> the two (very distinct in my opinion) features.

This is what the matching control is for. In any recent enough zsh you 
can do:

  compctl -M 'm:{a-z}={A-Z}'

to get the one-way-case-insesitiveness you described. The partial word 
completion can be allowed with:

  compctl -M 'r:|[._-]=* r:|=*'

See the compctl manual pages for further enlightenment.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Completion suggestions

[Oliver Kiddle]

On Feb 8, 10:12am, Sven Wischnowsky wrote:
> Oliver Kiddle wrote:
> > [ Quote aware completion suggestion ]
> 
> As an option, maybe. But if you have something like zsh -c "ls f<TAB>", 
> you'll want all files.

Good point. I suppose the option would have to be aware of quoting
outside the command so your example would work properly if zsh had a
compctl for -l after a -c option. I'm not sure how compctl -l deals
with quotes and -l doesn't seem to be working for me at the moment so I
can't test it.

I've made a couple of observations on differences between zsh and tcsh's
completion behaviour:
~ [68]% :> "a file"
~ [69]% less "a<tab>
tcsh completes to:
~ [69]% less "a file" _
whereas zsh completes to:
~ [69]% less "a file _
where the underscore is the cursor. I prefer tcsh's behaviour in this
case. Also, with the following:
~ [69]% less "a fi<tab>
tcsh completes as before but zsh treats us as being on the second word
so is completing files newly. I think zsh is being inconsistent as I
hope this will demonstrate:

compctl -x 'p[1]' -f - 'p[2]' -k '(a b c)' - 'p[3]' -k '(1 2 3)' -- t

While quotes are open, spaces within the quotes separate words:
~ [76]% t "a <tab>
a   b   c
~ [76]% t "a file <tab>
1   2   3
But when quotes are closed, a quoted area is all one word.
~ [76]% t "a file" <tab>
a   b   c
and backslash quoted spaces don't separate words
~ [76]% t a\ <tab>
~ [76]% t a\ file _
Note that single quotes behave in the same way as double quotes

It is difficult to say what the best thing to do is. I think zsh is
wrong because it is inconsistent but admit that it is more flexible than
tcsh because there is control of words within quotes. I don't think I've
needed this control in any of my compctls so would be in favour of
removing the inconsistency. Maybe what is needed is some way of
referencing words within quotes. e.g.
compctl -x 'p[1],qs[t]' -k '(1 2 3)' -- t
Where the q indicates that the pattern s[t] applies within the current
(quoted) word. I haven't had time to properly look at the new-style
completion yet but it might lend itself to a better solution.

> > Has any thought been given to implementing tcsh's complete=enhance
> This is what the matching control is for. In any recent enough zsh you 

fantastic thanks.

Seeing as there are no examples of matching control in compctl-examples
even though there are some in the documentation, I thought I'd
contribute my ncftp completion for it:

compctl -s '`sed -e 1,2d -e s/,.\*// < ~/.ncftp/bookmarks`' \
        -x 's[-]' -k '(a d C D f g G H L n p r R u V)' \
        - 'c[-1,-p]' -X 'Port number to dial' \
        - 'c[-1,-d]' -X 'Redial period (in seconds)' \
        - 'c[-1,-g]' -X 'No. of redials to give up after' \
        - 'c[-1,-n]' -X 'Max age of files to get (in days)' \
        - 'C[0,*.][0,*.*]' -s '`cut -d, -f2<~/.ncftp/bookmarks`' \
        -M 'm:{a-zA-Z}={A-Za-z} r:|.=* r:|=*' -- ncftp

It completes host nicknames from the ncftp bookmark file unless there is
a '.' in the word in which case full hostnames are completed.
The matching is used to treat hostnames as case-insensitive because
they are and to allow the cunning stuff with '.'. It also completes the
options but you might want to cut that out, especially as this was
written for version 3 beta which has different options to 2.x.

Oliver Kiddle

Re: Completion suggestions

[Bart Schaefer]

On Feb 14, 11:54am, Oliver Kiddle wrote:
} Subject: Re: Completion suggestions
}
} I've made a couple of observations on differences between zsh and tcsh's
} completion behaviour:
} ~ [68]% :> "a file"
} ~ [69]% less "a<tab>
} tcsh completes to:
} ~ [69]% less "a file" _
} whereas zsh completes to:
} ~ [69]% less "a file _
} where the underscore is the cursor. I prefer tcsh's behaviour in this
} case.

It's possible that quote handling could be made more context-sensitive.
In the absence of such sensitivity, I'd rather it behaved as it does now,
because with ordinary completion you never need the quotes:
    zsh% less a<TAB>
produces:
    zsh% less a\ file 
                      ^ cursor here

I made up this little function:

    __test() {
	for i in CONTEXT COMMAND IPREFIX PREFIX SUFFIX CURRENT argv
	    typeset $i
    }

Then bound it with zle -C and bindkey and tried your example above.  The
result, which of course scribbles all over the command line, is:

CONTEXT=argument
COMMAND=less
IPREFIX=''
PREFIX=''
SUFFIX=''
CURRENT=1
argv=(a)

Thus note that the quotes are gone by the time the completion code gets
a crack at the argument words.  This happens because zsh uses the parser
to scan the command line and determine the context.  In a new completion
function, however, we can also get at the LBUFFER and RBUFFER, so we
could look both ways to see if we're inside already closed quotes (for
completeinword) or are working on an open quote, and try to fix it up.

However, it's really difficult -- particularly in multi-line commands --
to decide whether you're inside an open quote.  For example, in

    zsh% ls '
    quote> "a

the value of LBUFFER is only the line at the secondary "quote> " prompt.
You can't tell that you're inside two different sets of open quotes by
looking at any of the variables (and of course the second quote isn't
really "open" because it's inside the first quote and therefore has no
syntactic significance).

} While quotes are open, spaces within the quotes separate words [...]
} But when quotes are closed, a quoted area is all one word.  [...]
} It is difficult to say what the best thing to do is. I think zsh is
} wrong because it is inconsistent but admit that it is more flexible than
} tcsh because there is control of words within quotes. I don't think I've
} needed this control in any of my compctls so would be in favour of
} removing the inconsistency.

Because, as I mentioned above, I never type the quotes at all unless I
mean for them to quote multiple words, I typically use this "inconsistent"
behaviour in ALL my completions that involve quoting.  Never having used
tcsh, I never had any reason to expect any other behavior.

} Maybe what is needed is some way of
} referencing words within quotes.

You first have to figure out that the words are within quotes; see the
multiline remarks above.  Tcsh doesn't have to deal with that, because
csh quotes may not be unmatched across multiple input lines.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Completion suggestions

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
>
> You first have to figure out that the words are within quotes; see the
> multiline remarks above.  Tcsh doesn't have to deal with that, because
> csh quotes may not be unmatched across multiple input lines.

I'm thinking about making the CONTEXT parameter in the new style
completion stuff an array giving mor information. It could then
contain information about the quoting zsh thinks is currently
used. However this would not solve `ls "a f<TAB>' since that would
require a change in the completion parsing, as Bart already said. To
model it after tcsh we would have to make the code take the whole
quoted (or half-quoted) string as the string to work upon, and add the 
closing quote automatically. But personally I don't like this, maybe
it's just a question of getting used to the way zsh works?
Also, I'm not too sure about adding a new `-x' test/modifier for this -
can one be sure to find all the places where one wants the whole
quoted string instead of only a part of it. And this would make
compctl's even more complicated. And finding out what to do in quoted
strings that contain quotes and backslashes and quoted quotes and so
on may get pretty complicated.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de