* GLOB_COMPLETE and numbered directories
@ 2015-03-19 7:32 Daniel Shahaf
2015-03-19 9:16 ` Mikael Magnusson
2015-03-19 16:06 ` Bart Schaefer
0 siblings, 2 replies; 10+ messages in thread
From: Daniel Shahaf @ 2015-03-19 7:32 UTC (permalink / raw)
To: zsh-users
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GLOB_COMPLETE and numbered directories
2015-03-19 7:32 GLOB_COMPLETE and numbered directories Daniel Shahaf
@ 2015-03-19 9:16 ` Mikael Magnusson
2015-03-19 23:15 ` Daniel Shahaf
2015-03-19 16:06 ` Bart Schaefer
1 sibling, 1 reply; 10+ messages in thread
From: Mikael Magnusson @ 2015-03-19 9:16 UTC (permalink / raw)
To: Daniel Shahaf; +Cc: Zsh Users
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GLOB_COMPLETE and numbered directories
2015-03-19 7:32 GLOB_COMPLETE and numbered directories Daniel Shahaf
2015-03-19 9:16 ` Mikael Magnusson
@ 2015-03-19 16:06 ` Bart Schaefer
2015-03-19 23:18 ` Daniel Shahaf
2015-03-20 1:02 ` Bart Schaefer
1 sibling, 2 replies; 10+ messages in thread
From: Bart Schaefer @ 2015-03-19 16:06 UTC (permalink / raw)
To: zsh-users
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GLOB_COMPLETE and numbered directories
2015-03-19 9:16 ` Mikael Magnusson
@ 2015-03-19 23:15 ` Daniel Shahaf
0 siblings, 0 replies; 10+ messages in thread
From: Daniel Shahaf @ 2015-03-19 23:15 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: Zsh Users
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GLOB_COMPLETE and numbered directories
2015-03-19 16:06 ` Bart Schaefer
@ 2015-03-19 23:18 ` Daniel Shahaf
2015-03-20 1:21 ` Bart Schaefer
2015-03-20 1:02 ` Bart Schaefer
1 sibling, 1 reply; 10+ messages in thread
From: Daniel Shahaf @ 2015-03-19 23:18 UTC (permalink / raw)
To: Bart Schaefer; +Cc: zsh-users
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GLOB_COMPLETE and numbered directories
2015-03-19 16:06 ` Bart Schaefer
2015-03-19 23:18 ` Daniel Shahaf
@ 2015-03-20 1:02 ` Bart Schaefer
2015-03-20 4:25 ` Daniel Shahaf
1 sibling, 1 reply; 10+ messages in thread
From: Bart Schaefer @ 2015-03-20 1:02 UTC (permalink / raw)
To: zsh-users
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GLOB_COMPLETE and numbered directories
2015-03-19 23:18 ` Daniel Shahaf
@ 2015-03-20 1:21 ` Bart Schaefer
2015-03-20 4:16 ` Daniel Shahaf
0 siblings, 1 reply; 10+ messages in thread
From: Bart Schaefer @ 2015-03-20 1:21 UTC (permalink / raw)
To: zsh-users
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GLOB_COMPLETE and numbered directories
2015-03-20 1:21 ` Bart Schaefer
@ 2015-03-20 4:16 ` Daniel Shahaf
0 siblings, 0 replies; 10+ messages in thread
From: Daniel Shahaf @ 2015-03-20 4:16 UTC (permalink / raw)
To: Bart Schaefer; +Cc: zsh-users
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?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GLOB_COMPLETE and numbered directories
2015-03-20 1:02 ` Bart Schaefer
@ 2015-03-20 4:25 ` Daniel Shahaf
2015-03-20 16:41 ` Bart Schaefer
0 siblings, 1 reply; 10+ messages in thread
From: Daniel Shahaf @ 2015-03-20 4:25 UTC (permalink / raw)
To: Bart Schaefer; +Cc: zsh-users
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GLOB_COMPLETE and numbered directories
2015-03-20 4:25 ` Daniel Shahaf
@ 2015-03-20 16:41 ` Bart Schaefer
0 siblings, 0 replies; 10+ messages in thread
From: Bart Schaefer @ 2015-03-20 16:41 UTC (permalink / raw)
To: zsh-users
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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2015-03-20 16:41 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-19 7:32 GLOB_COMPLETE and numbered directories Daniel Shahaf
2015-03-19 9:16 ` Mikael Magnusson
2015-03-19 23:15 ` Daniel Shahaf
2015-03-19 16:06 ` Bart Schaefer
2015-03-19 23:18 ` Daniel Shahaf
2015-03-20 1:21 ` Bart Schaefer
2015-03-20 4:16 ` Daniel Shahaf
2015-03-20 1:02 ` Bart Schaefer
2015-03-20 4:25 ` Daniel Shahaf
2015-03-20 16:41 ` Bart Schaefer
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).