* 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 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 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 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 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-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-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).