Re: something strange with delete-char-or-list

["Andrej Borsenkow" <Andrej.Borsenkow@xxxxxxxxxxxxxx>]

> > And related question:
> >
> > bor@itsrm2:~%> ls /a/p/u/z/*<TAB>
> > bor@itsrm2:~%> ls /archive/pub/unix/z/\*
> > zip/     zmodem/  zsh/
> >
> > Is it intentional, that pattern after the first ambiguous component is
> > preserved? (Oh, yes, I like it!) Is it possible to output it "as is" then
and
> > not quouted?
>
> We once had this, but that was a bug -- the path prefix and suffix
> wasn't quoted.
> I know that it would be nice to have this, but how should _path_files
> decide what should be quoted (e.g. a component like `foo bar') and
> what not (a pattern like `*[0-9]')?

1. I actually meant, is it possible to quote internally but display original
string. May be, it is impossible.

2. Unfortunately, we still have a clear bug:

bor@itsrm2:~%> l /a/p/u/z/\*<TAB><TAB>
bor@itsrm2:~%> l /archive/pub/unix/zip/\*
zip/     zmodem/  zsh/

now I press a-a-i-n-h and get

bor@itsrm2:~%> l /archive/pub/unix/zip/unzip532.tar.gz
unzip532.tar.gz   zcrypt27.zip      zip22.tar.gz
unzip540.tar.gz   zcrypt28.zip

That is, it is no more possible to distinguish between quoted and unquoted
string. I can no more complete literal '*' :-)

bor@itsrm2:~%> compconf -L
compconf correct_accept='2n'
compconf match_original='yes'
compconf completer='_oldlist:_complete:_match'
compconf dumpfile='/home/bor/.zcompdump'
compconf oldlist_list='_match'
compconf path_cursor='yes'
compconf match_insert='unambig'
compconf correct_prompt='correct to:'
bor@itsrm2:~%>

/andrej