GLOB_COMPLETE and numbered directories

GLOB_COMPLETE and numbered directories

[Daniel Shahaf]

Consider the following:

% zsh -f
% autoload compinit && compinit
% setopt globcomplete
% find
.
% mkdir -p {bar,baz}/iota
% cat b/i<TAB>
[cycles between 'cat ba<CURSOR>/iota', 'cat bar/iota/', 'cat baz/iota/']

The above works as expected.  However, if the directory names are
different, completion behaves differently:

% rm -rf bar baz
% mkdir -p {10a,11a}/iota
% cat 1/i<CURSOR>
[press <TAB>]
% cat 1<CURSOR>a/iota
[press <TAB>]
% cat 1a/iota<CURSOR>
[stays the same upon pressing TAB]

I expected the second <TAB> press to offer me the possible completions
'10a' '11a'.  I'd at least like not to be left with "1a/iota<CURSOR>"
since "1a" is not a possible completion or an existent directory, and
with the cursor far from the "1a" fixing the erroneous path requires too
much effort ;).

Cheers,

Daniel

Re: GLOB_COMPLETE and numbered directories

[Mikael Magnusson]

On Thu, Mar 19, 2015 at 8:32 AM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> Consider the following:
>
> % zsh -f
> % autoload compinit && compinit
> % setopt globcomplete
> % find
> .
> % mkdir -p {bar,baz}/iota
> % cat b/i<TAB>
> [cycles between 'cat ba<CURSOR>/iota', 'cat bar/iota/', 'cat baz/iota/']
>
> The above works as expected.  However, if the directory names are
> different, completion behaves differently:
>
> % rm -rf bar baz
> % mkdir -p {10a,11a}/iota
> % cat 1/i<CURSOR>
> [press <TAB>]
> % cat 1<CURSOR>a/iota
> [press <TAB>]
> % cat 1a/iota<CURSOR>
> [stays the same upon pressing TAB]
>
> I expected the second <TAB> press to offer me the possible completions
> '10a' '11a'.  I'd at least like not to be left with "1a/iota<CURSOR>"
> since "1a" is not a possible completion or an existent directory, and
> with the cursor far from the "1a" fixing the erroneous path requires too
> much effort ;).

Are you sure the difference isn't because your differing character is
now not the last character of the directory name?

-- 
Mikael Magnusson

Re: GLOB_COMPLETE and numbered directories

[Daniel Shahaf]

Mikael Magnusson wrote on Thu, Mar 19, 2015 at 10:16:02 +0100:
> On Thu, Mar 19, 2015 at 8:32 AM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > % mkdir -p {bar,baz}/iota
> > % cat b/i<TAB>
...
> > % mkdir -p {10a,11a}/iota
> > % cat 1/i<CURSOR>
> 
> Are you sure the difference isn't because your differing character is
> now not the last character of the directory name?

Yes, if I use 'bra' and 'bza' as the filenames, I get the same behaviour
as in the '10a'/'11a' case: it leaves me with 'ba/iota<CURSOR>'.  So
it's not about numbered directories, it's about disambiguating.

Thanks for pointing this out.

Daniel

Re: GLOB_COMPLETE and numbered directories

[Bart Schaefer]

On Mar 19,  7:32am, Daniel Shahaf wrote:
} Subject: GLOB_COMPLETE and numbered directories
}
} Consider the following:
} 
} % mkdir -p {bar,baz}/iota
} % cat b/i<TAB>
} [cycles between 'cat ba<CURSOR>/iota', 'cat bar/iota/', 'cat baz/iota/']

Not what I see here.
- First tab does ba<C>/iota
- Second tab shows list of bar/iota baz/iota below ba<C>/iota
- Third tab begins cycling bar/iota/ and baz/iota/

} % mkdir -p {10a,11a}/iota
} % cat 1/i<CURSOR>
} [press <TAB>]
} % cat 1<CURSOR>a/iota
} [press <TAB>]
} % cat 1a/iota<CURSOR>
} [stays the same upon pressing TAB]
} 
} I expected the second <TAB> press to offer me the possible completions
} '10a' '11a'.

With only glob_complete, it works by appending a * to the end of the word,
not by inserting a * at the cursor position.  1a*/iota* doesn't match
anything.

Any time the cursor is left in the middle of a word, it means that the
completion system is waiting for you to type a disambiguating character.

} I'd at least like not to be left with "1a/iota<CURSOR>"

It's supposed to be sufficient to "setopt completeinword" to get the
behavior you want, and indeed it works if I literally type out

% cat 1a/iota

and then move the cursor to 1<C>a/iota before pressing TAB.  However,
for some reason this doesn't happen when "continuing an in-progress
completion" with a second TAB.  I believe that's because the second
tab just regenerates the listing with the same pattern as on the
first tab, and that's not sufficient to disambiguate.

Re: GLOB_COMPLETE and numbered directories

[Daniel Shahaf]

Bart Schaefer wrote on Thu, Mar 19, 2015 at 09:06:12 -0700:
> On Mar 19,  7:32am, Daniel Shahaf wrote:
> } Subject: GLOB_COMPLETE and numbered directories
> }
> } Consider the following:
> } 
> } % mkdir -p {bar,baz}/iota
> } % cat b/i<TAB>
> } [cycles between 'cat ba<CURSOR>/iota', 'cat bar/iota/', 'cat baz/iota/']
> 
> Not what I see here.
> - First tab does ba<C>/iota
> - Second tab shows list of bar/iota baz/iota below ba<C>/iota
> - Third tab begins cycling bar/iota/ and baz/iota/
> 

That's exactly what I see, too.  Sorry for my inaccuracy.

> } % mkdir -p {10a,11a}/iota
> } % cat 1/i<CURSOR>
> } [press <TAB>]
> } % cat 1<CURSOR>a/iota
> } [press <TAB>]
> } % cat 1a/iota<CURSOR>
> } [stays the same upon pressing TAB]
> } 
> } I expected the second <TAB> press to offer me the possible completions
> } '10a' '11a'.
> 
> With only glob_complete, it works by appending a * to the end of the word,
> not by inserting a * at the cursor position.  1a*/iota* doesn't match
> anything.
> 
> Any time the cursor is left in the middle of a word, it means that the
> completion system is waiting for you to type a disambiguating character.
> 

Okay.

> } I'd at least like not to be left with "1a/iota<CURSOR>"
> 
> It's supposed to be sufficient to "setopt completeinword" to get the
> behavior you want, and indeed it works if I literally type out
> 
> % cat 1a/iota
> 
> and then move the cursor to 1<C>a/iota before pressing TAB.

It seems to work if I use <Left-arrow> to move the cursor, but not if
I use <M-b> to move the cursor.  Details:

If I type "cat 1a/iota<Left><Left><Left><Left><Left><Left><TAB>", I get
"10a/iota" and "11a/iota" offered below the input line (as in the second
<TAB> press in your description).

However, if I type "cat 1a/iota<M-b><Left><Left><TAB>", nothing happens,
even if I press <TAB> a few more times.

This is in XTerm(278) with TERM=xterm on Debian.  I invoked xterm as
   xterm -xrm 'XTerm*eightBitInput: false'
.  Without that resource, it behaves the same way except <Esc><b> is
required instead of <M-b>.

> However,
> for some reason this doesn't happen when "continuing an in-progress
> completion" with a second TAB.  I believe that's because the second
> tab just regenerates the listing with the same pattern as on the
> first tab, and that's not sufficient to disambiguate.

Okay.  Any pointers on how to get started on a fix?  I tried to have
a look at the code, starting with expandoncomplete() (the C function),
but got lost.

Thanks,

Daniel

Re: GLOB_COMPLETE and numbered directories

[Bart Schaefer]

On Mar 19, 11:18pm, Daniel Shahaf wrote:
}

[RE completeinword]

} It seems to work if I use <Left-arrow> to move the cursor, but not if
} I use <M-b> to move the cursor.  Details:
} 
} If I type "cat 1a/iota<Left><Left><Left><Left><Left><Left><TAB>", I get
} "10a/iota" and "11a/iota" offered below the input line (as in the second
} <TAB> press in your description).
} 
} However, if I type "cat 1a/iota<M-b><Left><Left><TAB>", nothing happens,
} even if I press <TAB> a few more times.

I can't reproduce this with "zsh -o globcomplete -o completeinword -f"
(and then compinit).

On the other hand <M-b> takes me all the way to "1" so I have to type
"cat 1a/iota<M-b><Right>" to get to the correct place to TAB.  So you
must have a diferent binding for M-b or a modified $WORDCHARS.

Re: GLOB_COMPLETE and numbered directories

[Daniel Shahaf]

Bart Schaefer wrote on Thu, Mar 19, 2015 at 18:21:27 -0700:
> On Mar 19, 11:18pm, Daniel Shahaf wrote:
> }
> 
> [RE completeinword]
> 
> } It seems to work if I use <Left-arrow> to move the cursor, but not if
> } I use <M-b> to move the cursor.  Details:
> } 
> } If I type "cat 1a/iota<Left><Left><Left><Left><Left><Left><TAB>", I get
> } "10a/iota" and "11a/iota" offered below the input line (as in the second
> } <TAB> press in your description).
> } 
> } However, if I type "cat 1a/iota<M-b><Left><Left><TAB>", nothing happens,
> } even if I press <TAB> a few more times.
> 
> I can't reproduce this with "zsh -o globcomplete -o completeinword -f"
> (and then compinit).
> 
> On the other hand <M-b> takes me all the way to "1" so I have to type
> "cat 1a/iota<M-b><Right>" to get to the correct place to TAB.  So you
> must have a diferent binding for M-b or a modified $WORDCHARS.

Neither.  Those results are in:

$ zsh -f
% autoload compinit; compinit; setopt globcomplete completeinword

and then entering "cat 1a/iota" and moving left.  I restarted the shell
before each attempt.  Using 'zsh -f' on zsh-5.0.7-348-gf48457a

Maybe it's a Debian patch to some dependency library?

Re: GLOB_COMPLETE and numbered directories

[Bart Schaefer]

On Mar 19,  9:06am, Bart Schaefer wrote:
}
} It's supposed to be sufficient to "setopt completeinword" to get the
} behavior you want, and indeed it works if I literally type out
} 
} % cat 1a/iota
} 
} and then move the cursor to 1<C>a/iota before pressing TAB.  However,
} for some reason this doesn't happen when "continuing an in-progress
} completion" with a second TAB.  I believe that's because the second
} tab just regenerates the listing with the same pattern as on the
} first tab, and that's not sufficient to disambiguate.

So ... in the case of moving the cursor to after the "1" and pressing
TAB, $PREFIX = "1".  But in the case of pressing the second TAB after
completing to "1a/iota", $PREFIX = "1a/iota" even though the cursor
is not at the end of the word.

The fix is therefore something like this, though I don't know if I have
handled completeinword correctly (as in, I think this generates matches
on a second TAB even when completeinword is not set, but I don't think
anyone would object to that?).

diff --git a/Completion/Base/Core/_main_complete b/Completion/Base/Core/_main_complete
index d6a1007..a89bc84 100644
--- a/Completion/Base/Core/_main_complete
+++ b/Completion/Base/Core/_main_complete
@@ -68,6 +68,15 @@ if [[ "$compstate[insert]" = tab* ]]; then
   compstate[insert]="${compstate[insert]//tab /}"
 fi
 
+# Second attempt at GLOB_COMPLETE
+
+if [[ "$compstate[pattern_match]" = "*" &&
+      "$_lastcomp[unambiguous]" = "$PREFIX" &&
+      -n "$_lastcomp[unambiguous_cursor]" ]]; then
+  integer upos="$_lastcomp[unambiguous_cursor]"
+  PREFIX="$PREFIX[1,upos-1]*$PREFIX[upos,-1]"
+fi
+
 # Special completion contexts after `~' and `='.
 
 if [[ -z "$compstate[quote]" ]]; then

Re: GLOB_COMPLETE and numbered directories

[Daniel Shahaf]

Bart Schaefer wrote on Thu, Mar 19, 2015 at 18:02:10 -0700:
> On Mar 19,  9:06am, Bart Schaefer wrote:
> }
> } It's supposed to be sufficient to "setopt completeinword" to get the
> } behavior you want, and indeed it works if I literally type out
> } 
> } % cat 1a/iota
> } 
> } and then move the cursor to 1<C>a/iota before pressing TAB.  However,
> } for some reason this doesn't happen when "continuing an in-progress
> } completion" with a second TAB.  I believe that's because the second
> } tab just regenerates the listing with the same pattern as on the
> } first tab, and that's not sufficient to disambiguate.
> 
> So ... in the case of moving the cursor to after the "1" and pressing
> TAB, $PREFIX = "1".  But in the case of pressing the second TAB after
> completing to "1a/iota", $PREFIX = "1a/iota" even though the cursor
> is not at the end of the word.
> 
> The fix is therefore something like this, though I don't know if I have
> handled completeinword correctly (as in, I think this generates matches
> on a second TAB even when completeinword is not set, but I don't think
> anyone would object to that?).
> 

'cat 1<C>a/iota<TAB>' behaves (with the patch) as follows:

- If this is the first tab and completeinword set: completes
- If this is the first tab and completeinword unset: doesn't complete
- If this is the second tab: completes

I think that's fine because, in the 'this is the second tab and
completeinword is unset' case, the _first_ tab was at the 'cat 1/i<C>'
case, so logically the overall completion that's happening here _is_
"completion at end of word", not in middle of word.

Thanks,

Daniel

> diff --git a/Completion/Base/Core/_main_complete b/Completion/Base/Core/_main_complete
> index d6a1007..a89bc84 100644
> --- a/Completion/Base/Core/_main_complete
> +++ b/Completion/Base/Core/_main_complete
> @@ -68,6 +68,15 @@ if [[ "$compstate[insert]" = tab* ]]; then
>    compstate[insert]="${compstate[insert]//tab /}"
>  fi
>  
> +# Second attempt at GLOB_COMPLETE
> +
> +if [[ "$compstate[pattern_match]" = "*" &&
> +      "$_lastcomp[unambiguous]" = "$PREFIX" &&
> +      -n "$_lastcomp[unambiguous_cursor]" ]]; then
> +  integer upos="$_lastcomp[unambiguous_cursor]"
> +  PREFIX="$PREFIX[1,upos-1]*$PREFIX[upos,-1]"
> +fi
> +
>  # Special completion contexts after `~' and `='.
>  
>  if [[ -z "$compstate[quote]" ]]; then

Re: GLOB_COMPLETE and numbered directories

[Bart Schaefer]

On Mar 20,  4:25am, Daniel Shahaf wrote:
}
} Bart Schaefer wrote on Thu, Mar 19, 2015 at 18:02:10 -0700:
} > So ... in the case of moving the cursor to after the "1" and pressing
} > TAB, $PREFIX = "1".  But in the case of pressing the second TAB after
} > completing to "1a/iota", $PREFIX = "1a/iota" even though the cursor
} > is not at the end of the word.
} > 
} > The fix is therefore something like this, though I don't know if I have
} > handled completeinword correctly (as in, I think this generates matches
} > on a second TAB even when completeinword is not set, but I don't think
} > anyone would object to that?).
} 
} 'cat 1<C>a/iota<TAB>' behaves (with the patch) as follows:
} 
} - If this is the first tab and completeinword set: completes
} - If this is the first tab and completeinword unset: doesn't complete
} - If this is the second tab: completes
} 
} I think that's fine because, in the 'this is the second tab and
} completeinword is unset' case, the _first_ tab was at the 'cat 1/i<C>'
} case, so logically the overall completion that's happening here _is_
} "completion at end of word", not in middle of word.

Upon consideration, I wonder if the following might not be preferable.  I
think the behavior described above remains unchanged.

I'm still puzzled as to why the internals don't do this correctly; the
cursor is obviously at the expected position.


diff --git a/Completion/Base/Core/_main_complete b/Completion/Base/Core/_main_complete
index d6a1007..977ab49 100644
--- a/Completion/Base/Core/_main_complete
+++ b/Completion/Base/Core/_main_complete
@@ -68,6 +68,16 @@ if [[ "$compstate[insert]" = tab* ]]; then
   compstate[insert]="${compstate[insert]//tab /}"
 fi
 
+# Second attempt at GLOB_COMPLETE
+
+if [[ "$compstate[pattern_match]" = "*" &&
+      "$_lastcomp[unambiguous]" = "$PREFIX" &&
+      -n "$_lastcomp[unambiguous_cursor]" ]]; then
+  integer upos="$_lastcomp[unambiguous_cursor]"
+  SUFFIX="$PREFIX[upos,-1]$SUFFIX"
+  PREFIX="$PREFIX[1,upos-1]"
+fi
+
 # Special completion contexts after `~' and `='.
 
 if [[ -z "$compstate[quote]" ]]; then