Re: Still something strange with ambiguous prefix

Re: Still something strange with ambiguous prefix

[Sven Wischnowsky]

I wrote:

> Andrej Borsenkow wrote:
> > 
> > bor@itsrm2:~%> l /t/s/gl/co*TAB
> > bor@itsrm2:~%> l /tools/src/glib-1.1.15/co* <= cursor here
> > glib-1.1.15/  glib-1.2.0/
> > 
> > So, menu completion is started for prefix, but cursor is placed at the end
> > of word.
>
> Anyway, I don't know how I should change this easily for now. The
> problem is that the path suffix is just an ignored suffix for the
> completion code and normally one really wants to have the cursor at
> the end of the whole word with menu-completion.
> We could add a flag stored with each match and add an option for
> `compadd' to turn this on which would make the cursor be left before
> that suffix.
> But I'd really like to hear at least one comment from someone else
> using menucompletion before doing this (hm, although, maybe if we add
> another configuration key..., yes maybe I'll produce a patch for this
> sometime).

I should have thought about ALWAYS_TO_END. Without the patch below it
doesn't do what Andrej requested, but maybe it should be made to do
that.
Previously it left the cursor in the word only if completion was
started with the cursor in the word.

Dunno if this is the right thing to do and I don't want to decide it.

Bye
 Sven

diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c	Thu Mar 25 18:08:58 1999
+++ Src/Zle/zle_tricky.c	Fri Mar 26 09:08:20 1999
@@ -6721,7 +6721,8 @@
 	/* We are currently not in a menu-completion, *
 	 * so set the position variables.             */
 	menupos = wb;
-	menuwe = (cs == we) || isset(ALWAYSTOEND);
+	/* previously:	menuwe = (cs == we) || isset(ALWAYSTOEND); */
+	menuwe = isset(ALWAYSTOEND);
 	menuend = we;
     }
     /* If we are already in a menu-completion or if we have done a *

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

Re: Still something strange with ambiguous prefix

[Peter Stephenson]

Sven Wischnowsky wrote:
> Previously it left the cursor in the word only if completion was
> started with the cursor in the word.

I should have thought that was correct?  I can't imagine wanting it
otherwise.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: Still something strange with ambiguous prefix

[Sven Wischnowsky]

Peter Stephenson wrote:

> Sven Wischnowsky wrote:
> > Previously it left the cursor in the word only if completion was
> > started with the cursor in the word.
> 
> I should have thought that was correct?  I can't imagine wanting it
> otherwise.

Aha, I almost thought so already.

I'm currently working on the rest of the things I want to put in
`compstate'. There will be an entry for modifying this behavior and
I'll make it a bit more powerful so that the old behavior (depending
on alwaystoend) will be the default but inside completion widgets one
can specify what exactly one wants.

Bye
 Sven


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

RE: Still something strange with ambiguous prefix

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> itsrm2% bindkey '^I' complete-word
> itsrm2% fpath=($PWD/*(/))
> itsrm2% . Core/compinit
> itsrm2% compconf completer=_complete:_match match_original=yes
> itsrm2% l /t/s/z/D/z*iTAB
> itsrm2% l /tools/src/zsh-3.1.5-pws-13/Doc/zsh.info
> zsh.info         zsh.info-5       zshbuiltins.1    zshoptions.1
> zsh.info-1       zsh.info-6       zshbuiltins.yo   zshoptions.yo
> zsh.info-10      zsh.info-7       zshcompwid.1     ztexi.yo
> zsh.info-2       zsh.info-8       zshcompwid.yo
> zsh.info-3       zsh.info-9       zshmisc.1
> zsh.info-4       zsh.texi         zshmisc.yo

I tested it with a local directory (not `/...'), sorry. There a
different branch was called and it worked. Try the one below. Ok?

> > > 3.
> > >
> > > bor@itsrm2:~%> l /t/s/gl/co*TAB
> > > bor@itsrm2:~%> l /tools/src/glib-1.1.15/co* <= cursor here
> > > glib-1.1.15/  glib-1.2.0/
> > >
> > > So, menu completion is started for prefix, but cursor is placed
> > at the end
> > > of word.
> >
> > Grrrr, I asked if you wanted the cursor placed in the middle of the
> > word with menu-completion in message 5651 and you answered `Me not' in
> > message 5657.
> >
> 
> a) (with the same zsh as in 2)
> 
> itsrm2% l /u/l/lTAB
> itsrm2% l /u/l/l
>             ^ cursor here (after `/u')
> u1/   usr/
> 
> May I kindly ask, what is the difference between this ang glib example?

Menucompletion. In menucompletion the cursor was always moved to the
end, but not for normal completion.

> > Anyway, I don't know how I should change this easily for now. The
> > problem is that the path suffix is just an ignored suffix for the
> > completion code and normally one really wants to have the cursor at
> > the end of the whole word with menu-completion.
> 
> That makes sense, if we complete the whole word. But what happens here -
> that we actually complete just a single part of it. When I said "yes" to
> your question - I implied, that a user will be presented with the complete
> list (in the above example, this would mean *all* files that match gl*/co*).
> Simply, because it was what compctl always did, and I was accustomed to it.
> All of you said, it is "the bad thing". Now, after actually using it, I
> agree.

In normal usage the cursor can be where you want and TAB should give
some reasonable result. With menucompletion (where anything that is
inserted is the full string) putting the cursor at the end may save
you some nasty moving-the-curosr-to-the-end-of-it which would have to
be done by hand.

Bye
 Sven

diff -u -r oc/Base/_long_options Completion/Base/_long_options
--- oc/Base/_long_options	Thu Mar 25 15:31:24 1999
+++ Completion/Base/_long_options	Thu Mar 25 18:01:10 1999
@@ -215,8 +215,6 @@
 
   [[ -n "$_comp_correct" ]] && patflags="$patflags(#a$_comp_correct)"
 
-  [[ "${compstate[pattern_match]-*}" != \** ]] && pat="$pat:gs/*//"
-
   # Then we walk through the array names. For each array we test if it 
   # contains the option string. If so, we `invoke' the action stored
   # with the name. If the action is a list of words, we just add them, 
diff -u -r oc/Core/_multi_parts Completion/Core/_multi_parts
--- oc/Core/_multi_parts	Thu Mar 25 15:31:27 1999
+++ Completion/Core/_multi_parts	Thu Mar 25 18:00:09 1999
@@ -45,7 +45,11 @@
 # the original string in `orig'.
 
 if [[ $#compstate[pattern_match] -ne 0 ]]; then
-  patstr="${PREFIX}*${SUFFIX}*"
+  if [[ "${compstate[pattern_match]-*}" = \** ]]; then
+    str="${PREFIX}*${SUFFIX}*"
+  else
+    str="${PREFIX}${SUFFIX}"
+  fi
 else
   patstr="${PREFIX:q}*${SUFFIX:q}*"
 fi
@@ -61,8 +65,6 @@
 [[ -n "$_comp_correct" ]] && matchflags="$matchflags(#a$_comp_correct)"
 
 patstr="${${patstr//$sep/*$sep}//\*##/*}"
-
-[[ "${compstate[pattern_match]-*}" != \** ]] && patstr="$patstr:gs/*//"
 
 # First we will skip over those parts of the matches for which we have 
 # exact substrings on the line. In `pref' we will build the
diff -u -r oc/Core/_path_files Completion/Core/_path_files
--- oc/Core/_path_files	Thu Mar 25 15:31:27 1999
+++ Completion/Core/_path_files	Thu Mar 25 18:00:19 1999
@@ -113,7 +113,11 @@
 # the prefix and the suffix. Then we see if we will do menucompletion.
 
 if [[ $#compstate[pattern_match] -ne 0 ]]; then
-  str="${PREFIX}*${SUFFIX}"
+  if [[ "${compstate[pattern_match]-*}" = \** ]]; then
+    str="${PREFIX}*${SUFFIX}"
+  else
+    str="${PREFIX}${SUFFIX}"
+  fi
 else
   str="${PREFIX:q}*${SUFFIX:q}"
   [[ "$str" = \\\~* ]] && str="$str[2,-1]"
@@ -212,8 +216,6 @@
 # add the pattern for matching any characters before a slash.
 
 patstr="$patstr:gs-/-*/-:gs/*.*./../:gs/**/*/:gs-.*/-./-"
-
-[[ "${compstate[pattern_match]-*}" != \** ]] && patstr="$patstr:gs/*//"
 
 # We take the last pathname component from the pattern and store it in
 # `patlast', replacing `*'s in it with patterns that match any character
diff -u -r oc/Core/_sep_parts Completion/Core/_sep_parts
--- oc/Core/_sep_parts	Thu Mar 25 15:31:27 1999
+++ Completion/Core/_sep_parts	Thu Mar 25 18:00:38 1999
@@ -69,8 +69,6 @@
   _match_pattern _sep_parts test matchflags
   [[ -n "$_comp_correct" ]] && matchflags="$matchflags(#a$_comp_correct)"
 
-  [[ "${compstate[pattern_match]-*}" != \** ]] && test="$test:gs/*//"
-
   test="${matchflags}${test}"
   testarr=( "${(@M)${(@P)arr}:#${~test}*}" )
   testarr=( "${(@)testarr:#}" )

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

Re: Still something strange with ambiguous prefix

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> 1.
> 
> bor@itsrm2:~%> sudo mkdir -p /foo/{bar,bar1}
> bor@itsrm2:~%> sudo touch /foo/{bar,bar1}/baz
> bor@itsrm2:~%> l /f/b/bTAB
> bor@itsrm2:~%> l /foo/bar/baz
> 
> That is strange. bar1 seems to be never completed. (I noted it as we have
> both /usr/lib and /usr/lib64s with (basically) the same contents). I'd
> expect it to menu complete {bar,bar1}

It was there but the cursor didn't get placed at the right position
(with `unsetopt listambiguous' you would have seen it). Fixed by the
patch below.
And it does menu-completion for me. But it does not do automenu,
because before that the completion gets called a second time and then
the code in `_path_files' sees that `/foo/bar/baz' matches only one
file.

> 2.
> 
> bor@itsrm2:~> l /t/s/z/D/z*iTAB
> bor@itsrm2:~%> l /tools/src/zsh-3.1.5-pws-13/Doc/zsh.info
> zsh.info         zsh.info-5       zshbuiltins.1    zshoptions.1
> zsh.info-1       zsh.info-6       zshbuiltins.yo   zshoptions.yo
> zsh.info-10      zsh.info-7       zshcompwid.1     ztexi.yo
> zsh.info-2       zsh.info-8       zshcompwid.yo
> zsh.info-3       zsh.info-9       zshmisc.1
> zsh.info-4       zsh.texi         zshmisc.yo
> 
> Yesterday it completed just to zsh.texi

(globcomplete turned on, I guess.)

This one again? With completeinword, no `*', and the cursor before the 
`i' it worked. With globcomplete set (as I guess you have) this is
*correct* behavior. Correct in the sense that it always has been like
that. And no, I don't want to change it. Compatibility and all that.

Because of this I have written the `_match' completer:

  bindkey '^I' complete-word
  unsetopt globcomplete        # yes, it's off by default
  source .../compinit ...
  compconf completer=_complete:_match match_original=yes

in your `.zshrc'. Or `only' instead of `yes' if you prefer.

> 3.
> 
> bor@itsrm2:~%> l /t/s/gl/co*TAB
> bor@itsrm2:~%> l /tools/src/glib-1.1.15/co* <= cursor here
> glib-1.1.15/  glib-1.2.0/
> 
> So, menu completion is started for prefix, but cursor is placed at the end
> of word.

Grrrr, I asked if you wanted the cursor placed in the middle of the
word with menu-completion in message 5651 and you answered `Me not' in 
message 5657.

Anyway, I don't know how I should change this easily for now. The
problem is that the path suffix is just an ignored suffix for the
completion code and normally one really wants to have the cursor at
the end of the whole word with menu-completion.
We could add a flag stored with each match and add an option for
`compadd' to turn this on which would make the cursor be left before
that suffix.
But I'd really like to hear at least one comment from someone else
using menucompletion before doing this (hm, although, maybe if we add
another configuration key..., yes maybe I'll produce a patch for this
sometime).

> 4. It seems to be impossible to complete only prefix in /u/i/s/*.h (oh, I
> like this example :-) Reading README, _expand completer has a
> expand_original option, that makes it include original string in a set of
> matches. What about something like it for _match as well (with intention,
> that it should be used by _path_files also)? I understand, that it probably
> needs either another member to compstate - or probably we could add special
> value of pattern_insert? With meaning "menu completion with original
> pattern"?

Have you tried playing with `compconf path_expand=yes'? May I remind
you of 5917 (unsetting GLOB_COMPLETE, which is rather superfluous with
`_match' and using complete-word)?

Such a prefix-expansion has nothing to do with `compstate' -- as soon
as `_path_files' is used all the matching is done there and it also
says exactly what should be inserted and how all the strings for the
matches look like.

Also, I don't understand which connection you want to have between
`_match' and `_path_files'.

> Just a comment - I personally would prefer dots for options names:
> expand.menu, match.original etc. It gives more "multilevel" impression -
> e.g. if we decide to add more precise options to match.original, they could
> be match.original.foo, match.original.bar etc.
> And it is so Tcl'ish ... :-)

;-) I actually had this but then wanted to keep you happy by not
forcing you to have all your `compconf's changed. On the other hand,
the completion code is almost completely underscore-based, if you get my 
meaning. (And *TCL*? Bleah ;-)

Bye
 Sven

diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c	Thu Mar 25 15:31:01 1999
+++ Src/Zle/zle_tricky.c	Thu Mar 25 16:29:38 1999
@@ -3049,6 +3049,8 @@
 	p = o;
 	o = o->next;
     }
+    if (md.len || md.cl)
+	ot->flags |= CLF_MISS;
     if (orest)
 	*orest = NULL;
     if (nrest)

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

RE: Still something strange with ambiguous prefix

[Andrej Borsenkow]

>
> > 2.
> >
> > bor@itsrm2:~> l /t/s/z/D/z*iTAB
> >
> > Yesterday it completed just to zsh.texi
>
> (globcomplete turned on, I guess.)
>
> This one again? With completeinword, no `*', and the cursor before the
> `i' it worked. With globcomplete set (as I guess you have) this is
> *correct* behavior. Correct in the sense that it always has been like
> that. And no, I don't want to change it. Compatibility and all that.
>
> Because of this I have written the `_match' completer:
>

We are back here again (remember, I quoted part of my ~/.zshrc in my
message).

bor@itsrm2:/tools/src/zsh-3.1.5-pws-13/Completion%> zsh -f
itsrm2% bindkey '^I' complete-word
itsrm2% fpath=($PWD/*(/))
itsrm2% . Core/compinit
itsrm2% compconf completer=_complete:_match match_original=yes
itsrm2% l /t/s/z/D/z*iTAB
itsrm2% l /tools/src/zsh-3.1.5-pws-13/Doc/zsh.info
zsh.info         zsh.info-5       zshbuiltins.1    zshoptions.1
zsh.info-1       zsh.info-6       zshbuiltins.yo   zshoptions.yo
zsh.info-10      zsh.info-7       zshcompwid.1     ztexi.yo
zsh.info-2       zsh.info-8       zshcompwid.yo
zsh.info-3       zsh.info-9       zshmisc.1
zsh.info-4       zsh.texi         zshmisc.yo

>
> > 3.
> >
> > bor@itsrm2:~%> l /t/s/gl/co*TAB
> > bor@itsrm2:~%> l /tools/src/glib-1.1.15/co* <= cursor here
> > glib-1.1.15/  glib-1.2.0/
> >
> > So, menu completion is started for prefix, but cursor is placed
> at the end
> > of word.
>
> Grrrr, I asked if you wanted the cursor placed in the middle of the
> word with menu-completion in message 5651 and you answered `Me not' in
> message 5657.
>

a) (with the same zsh as in 2)

itsrm2% l /u/l/lTAB
itsrm2% l /u/l/l
            ^ cursor here (after `/u')
u1/   usr/

May I kindly ask, what is the difference between this ang glib example?

b) Yes, I beg your pardon. But since then I actually used new completion for
some time - and it provides sometimes very different possibilities. And you
begin to think a bit differently ...

> Anyway, I don't know how I should change this easily for now. The
> problem is that the path suffix is just an ignored suffix for the
> completion code and normally one really wants to have the cursor at
> the end of the whole word with menu-completion.

That makes sense, if we complete the whole word. But what happens here -
that we actually complete just a single part of it. When I said "yes" to
your question - I implied, that a user will be presented with the complete
list (in the above example, this would mean *all* files that match gl*/co*).
Simply, because it was what compctl always did, and I was accustomed to it.
All of you said, it is "the bad thing". Now, after actually using it, I
agree.


cheers

/andrej

the patch list I have (after pws-13):

5868
5871
5872
5875
5889
5890
5895
5898
5899
5904
5905
5906
5912
5913
5914
5915
5916
5918
5925
5926
5928
5931
5933
5934

Still something strange with ambiguous prefix

[Andrej Borsenkow]

After applying all patches (except compset) and using


bindkey -e
bindkey '\033^M' accept-and-menu-complete
bindkey '^I' complete-word
bindkey '^[q' push-line-or-edit

##
## New completion
##

fpath=(~/.zsh.d/Completion/* "$fpath[@]")
source ~/.zsh.d/Completion/Core/compinit
compconf completer=_complete:_match
compconf match_original=yes

1.

bor@itsrm2:~%> sudo mkdir -p /foo/{bar,bar1}
bor@itsrm2:~%> sudo touch /foo/{bar,bar1}/baz
bor@itsrm2:~%> l /f/b/bTAB
bor@itsrm2:~%> l /foo/bar/baz

That is strange. bar1 seems to be never completed. (I noted it as we have
both /usr/lib and /usr/lib64s with (basically) the same contents). I'd
expect it to menu complete {bar,bar1}

2.

bor@itsrm2:~> l /t/s/z/D/z*iTAB
bor@itsrm2:~%> l /tools/src/zsh-3.1.5-pws-13/Doc/zsh.info
zsh.info         zsh.info-5       zshbuiltins.1    zshoptions.1
zsh.info-1       zsh.info-6       zshbuiltins.yo   zshoptions.yo
zsh.info-10      zsh.info-7       zshcompwid.1     ztexi.yo
zsh.info-2       zsh.info-8       zshcompwid.yo
zsh.info-3       zsh.info-9       zshmisc.1
zsh.info-4       zsh.texi         zshmisc.yo

Yesterday it completed just to zsh.texi

3.

bor@itsrm2:~%> l /t/s/gl/co*TAB
bor@itsrm2:~%> l /tools/src/glib-1.1.15/co* <= cursor here
glib-1.1.15/  glib-1.2.0/

So, menu completion is started for prefix, but cursor is placed at the end
of word.

4. It seems to be impossible to complete only prefix in /u/i/s/*.h (oh, I
like this example :-) Reading README, _expand completer has a
expand_original option, that makes it include original string in a set of
matches. What about something like it for _match as well (with intention,
that it should be used by _path_files also)? I understand, that it probably
needs either another member to compstate - or probably we could add special
value of pattern_insert? With meaning "menu completion with original
pattern"?

Just a comment - I personally would prefer dots for options names:
expand.menu, match.original etc. It gives more "multilevel" impression -
e.g. if we decide to add more precise options to match.original, they could
be match.original.foo, match.original.bar etc.
And it is so Tcl'ish ... :-)

cheers

/andrej