zsh-users
 help / color / mirror / code / Atom feed
* cd /u/N/v/ tab expansion
@ 2022-04-06 12:40 zzapper
  2022-04-07 20:11 ` Bart Schaefer
  0 siblings, 1 reply; 20+ messages in thread
From: zzapper @ 2022-04-06 12:40 UTC (permalink / raw)
  To: Zsh-Users List

Hi

cd /u/N/v/  # tab expands to

cd /usr/NX/var/

This works well if /u/N/v/ is unique and oddly or not all if not..


Q1) where is the doc for this?


Has something in my setup overloaded this?


zzapper





^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: cd /u/N/v/ tab expansion
  2022-04-06 12:40 cd /u/N/v/ tab expansion zzapper
@ 2022-04-07 20:11 ` Bart Schaefer
  2022-04-07 20:20   ` zzapper
  0 siblings, 1 reply; 20+ messages in thread
From: Bart Schaefer @ 2022-04-07 20:11 UTC (permalink / raw)
  To: zzapper; +Cc: Zsh-Users List

On Wed, Apr 6, 2022 at 5:41 AM zzapper <zsh@rayninfo.co.uk> wrote:
>
> cd /u/N/v/  # tab expands to
>
> cd /usr/NX/var/

This is what _path_files does.

> This works well if /u/N/v/ is unique and oddly or not all if not..

What's odd about it?  The behavior should be that the unambiguous part
at the left is completed, and then the cursor stops at the first
ambiguous point.  For example, if I do:

% ls /u/l/b<TAB>

I get, with cursor after the "l" (over the third "/"):

% ls /usr/l/b

If I hit TAB again:

% ls /usr/l/b
libexec/  local/

When does this fail for you?

> Q1) where is the doc for this?

Under the entry for _path_files.

> Has something in my setup overloaded this?

No way for us to tell.  Have you tried using the ctrl+x question-mark
binding to get a completion traceback?


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: cd /u/N/v/ tab expansion
  2022-04-07 20:11 ` Bart Schaefer
@ 2022-04-07 20:20   ` zzapper
  2022-04-07 23:11     ` Bart Schaefer
  0 siblings, 1 reply; 20+ messages in thread
From: zzapper @ 2022-04-07 20:20 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh-Users List

> What's odd about it?  The behavior should be that the unambiguous part
> at the left is completed, and then the cursor stops at the first
> ambiguous point.  For example, if I do:
>
> % ls /u/l/b<TAB>
>
> I get, with cursor after the "l" (over the third "/"):
>
> % ls /usr/l/b
>
> If I hit TAB again:
>
> % ls /usr/l/b
> libexec/  local/
>
> When does this fail for you?
>
>> Q1) where is the doc for this?
> Under the entry for _path_files.
>
>> Has something in my setup overloaded this?
> No way for us to tell.  Have you tried using the ctrl+x question-mark
> binding to get a completion traceback?

Thanks Bart, I will try and be more precise my 'oddly' and report back 
to this thread.

One issue I had was that it was only offering me two of the possible 6 
sub-directories

> zzapper


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: cd /u/N/v/ tab expansion
  2022-04-07 20:20   ` zzapper
@ 2022-04-07 23:11     ` Bart Schaefer
  2022-04-08  9:53       ` zzapper
                         ` (2 more replies)
  0 siblings, 3 replies; 20+ messages in thread
From: Bart Schaefer @ 2022-04-07 23:11 UTC (permalink / raw)
  To: zzapper; +Cc: Zsh-Users List

On Thu, Apr 7, 2022 at 1:20 PM zzapper <zsh@rayninfo.co.uk> wrote:
>
> > % ls /usr/l/b
> >
> > If I hit TAB again:
> >
> > % ls /usr/l/b
> > libexec/  local/
>
> One issue I had was that it was only offering me two of the possible 6
> sub-directories

If you look at my example, I was only offered libexec and local even
though there is a /usr/lib directory.  But there's no file matching
"b*" in /usr/lib, so "lib" is excluded.


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: cd /u/N/v/ tab expansion
  2022-04-07 23:11     ` Bart Schaefer
@ 2022-04-08  9:53       ` zzapper
  2022-04-08 17:57         ` Bart Schaefer
  2022-04-08 10:22       ` david rayner
  2022-04-10  1:04       ` Tomasz Pala
  2 siblings, 1 reply; 20+ messages in thread
From: zzapper @ 2022-04-08  9:53 UTC (permalink / raw)
  To: zsh-users


On 08/04/2022 00:11, Bart Schaefer wrote:
> On Thu, Apr 7, 2022 at 1:20 PM zzapper <zsh@rayninfo.co.uk> wrote:
>>> % ls /usr/l/b
>>>
>>> If I hit TAB again:
>>>
>>> % ls /usr/l/b
>>> libexec/  local/
>> One issue I had was that it was only offering me two of the possible 6
>> sub-directories
> If you look at my example, I was only offered libexec and local even
> though there is a /usr/lib directory.  But there's no file matching
> "b*" in /usr/lib, so "lib" is excluded.
>
OMG that's subtle & clever

(My expansions work better in an zsh -f clean environment)

Where does it specify that this feature only(?) works with one initial 
letter?


zzapper



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: cd /u/N/v/ tab expansion
  2022-04-07 23:11     ` Bart Schaefer
  2022-04-08  9:53       ` zzapper
@ 2022-04-08 10:22       ` david rayner
  2022-04-08 18:09         ` Bart Schaefer
  2022-04-10  1:04       ` Tomasz Pala
  2 siblings, 1 reply; 20+ messages in thread
From: david rayner @ 2022-04-08 10:22 UTC (permalink / raw)
  To: zsh-users


On 08/04/2022 00:11, Bart Schaefer wrote:
> On Thu, Apr 7, 2022 at 1:20 PM zzapper <zsh@rayninfo.co.uk> wrote:
>>> % ls /usr/l/b
>>>
>>> If I hit TAB again:
>>>
>>> % ls /usr/l/b
>>> libexec/  local/
>> One issue I had was that it was only offering me two of the possible 6
>> sub-directories
> If you look at my example, I was only offered libexec and local even
> though there is a /usr/lib directory.  But there's no file matching
> "b*" in /usr/lib, so "lib" is excluded.
>
Wow in the end my problem was all PEBCAK

zsh can only complete if there is one or more existing set of 
subdirectories

e.g.

cd /z/z/z will not expand as no such hierarchy exists on my pc but as 
you get no warning message you may (incorrectly) think the feature isn't 
working

whereas

cd /e/X/f/<tab>

successfully expands to

cd /etc/X11/fonts/



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: cd /u/N/v/ tab expansion
  2022-04-08  9:53       ` zzapper
@ 2022-04-08 17:57         ` Bart Schaefer
  0 siblings, 0 replies; 20+ messages in thread
From: Bart Schaefer @ 2022-04-08 17:57 UTC (permalink / raw)
  To: zzapper; +Cc: Zsh Users

On Fri, Apr 8, 2022 at 2:53 AM zzapper <zsh@rayninfo.co.uk> wrote:
>
]> Where does it specify that this feature only(?) works with one initial
> letter?

It actually should work with any number of initial letters (in each
path segment), but it doesn't look for substrings anywhere other than
as prefixes.


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: cd /u/N/v/ tab expansion
  2022-04-08 10:22       ` david rayner
@ 2022-04-08 18:09         ` Bart Schaefer
  0 siblings, 0 replies; 20+ messages in thread
From: Bart Schaefer @ 2022-04-08 18:09 UTC (permalink / raw)
  To: Zsh Users

On Fri, Apr 8, 2022 at 3:22 AM david rayner <david@rayninfo.co.uk> wrote:
>
> cd /z/z/z will not expand as no such hierarchy exists on my pc but as
> you get no warning message you may (incorrectly) think the feature isn't
> working

You should get a beep unless you have the "nobeep" setopt.

And if you have a zstyle for the 'format' tag, you get visual feedback:

% zstyle ':completion:*' format %d
% cd /z/z/z<TAB>
`file'


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: cd /u/N/v/ tab expansion
  2022-04-07 23:11     ` Bart Schaefer
  2022-04-08  9:53       ` zzapper
  2022-04-08 10:22       ` david rayner
@ 2022-04-10  1:04       ` Tomasz Pala
  2022-04-10 14:32         ` Tomasz Pala
  2 siblings, 1 reply; 20+ messages in thread
From: Tomasz Pala @ 2022-04-10  1:04 UTC (permalink / raw)
  To: Bart Schaefer

On Thu, Apr 07, 2022 at 16:11:37 -0700, Bart Schaefer wrote:

>> One issue I had was that it was only offering me two of the possible 6
>> sub-directories
> 
> If you look at my example, I was only offered libexec and local even
> though there is a /usr/lib directory.  But there's no file matching
> "b*" in /usr/lib, so "lib" is excluded.

I've stuck with this problem month ago...

$ cd /e/s/s/[tab]
No matches for: `directory'

while
$ cd /e/s/s[tab] -- note the missing '/' at the end works.

$ cd /etc/s/s/i[tab]
No matches for: `directory'

-- I got /etc/systemd/system/input.target.wants/ there.

It seems the problem is the ambiguousness of the 's'.


There are other oddities:

$ cd /u/s/e/s[tab]
No matches for: `directory'
$ ls /u/s/e/s[tab]
ekg2/session-en.txt        ekg2/session-pl.txt	epsg_csv/stateplane.csv    epsg_csv/supersession.csv

while there is /usr/share/ekg2/scripts directory...


$ ls /usr/src/l/drivers/n/ethernet/i[tab]
No matches for: `files' or `directory'
$ ls /usr/src/l/drivers/net/ethernet/i[tab] -- 'n' replaced with 'net'
directory
linux-4.4-4.4.14/drivers/net/ethernet/i825xx/  linux-4.4/drivers/net/ethernet/i825xx/         linux-5.9.6/drivers/net/ethernet/i825xx/                                                    
linux-4.4-4.4.14/drivers/net/ethernet/ibm/     linux-4.4/drivers/net/ethernet/ibm/            linux-5.9.6/drivers/net/ethernet/ibm/                                                       
linux-4.4-4.4.14/drivers/net/ethernet/intel/   linux-4.4/drivers/net/ethernet/intel/          linux-5.9.6/drivers/net/ethernet/intel/                                                     

$ ls /usr/src/linux-5.9.6/drivers/net/e/i/e/e[tab]
No matches for: `files' or `directory'
e.g. /usr/src/linux-5.9.6/drivers/net/ethernet/ibm/ehea/ehea.h existing
there matches and should be presented.

Simple test:
$ mkdir -p  a/{b1,b2}/d/{e1,e2}/g
$ cd a/b/d/e/g[tab] == nothing
$ cd a/b1/d/e/g[tab] == e1/g e2/g


The problem was this single line:

zstyle ':completion:*:*:*:*' list-suffixes yes


-- 
Tomasz Pala <gotar@pld-linux.org>


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: cd /u/N/v/ tab expansion
  2022-04-10  1:04       ` Tomasz Pala
@ 2022-04-10 14:32         ` Tomasz Pala
  2022-04-10 16:27           ` Tomasz Pala
  2022-04-17  3:00           ` Bart Schaefer
  0 siblings, 2 replies; 20+ messages in thread
From: Tomasz Pala @ 2022-04-10 14:32 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: zsh-users

On Sun, Apr 10, 2022 at 03:04:41 +0200, Tomasz Pala wrote:

> I've stuck with this problem month ago...
> 
> $ cd /e/s/s/[tab]
> No matches for: `directory'

This happens with: setopt glob_complete interfering with

zstyle ':completion:*' list-dirs-first true

According to the docs this should not be correlated.
For me it seems that list-dirs-first is somehow broken. I got other
usecases with bogus sets in menu completion.

Namely:

$ mkdir -p usr/{share/{aclocal,atever},sbin,src}
$ touch usr/sbin/a1 usr/share/a1 usr/share/a2
$ zstyle ':completion:*' list-dirs-first true

$ ls u/s*/a[tab]
directory
aclocal/  atever/

after second tab:
directory
aclocal/  atever/
files
a1        a2

- the problem is there is only ONE a1 file proposed and this is
usr/share/a1, usr/sbin/a1 doesn't get to the list at all!
Or it's overaggregated (disregarding directory).


$ ls u/s*/a*[tab]	note the asterisk after "a"
directory
aclocal/  atever/
files
sbin/     share/

- this is much better, as sbin/ and share/ are completed to "sbin/a*"
and share/a*, so after the initial selection one can start second
completion resolving "a*" part.


My solution was to use:

zstyle ':completion:*:*:*:*' list-suffixes yes

but then:

$ mkdir -p  a/{b1,b2}/d/{e1,e2}/g
$ ls a/b/d/e/g[tab]
No matches for: `files' or `directory'

And after:
$ zstyle ':completion:*' list-dirs-first false
$ ls a/b/d/e/g[tab]
No matches for: `files'

- slightly different response only.


This behaviour also doesn't match the docs - enabling list-suffixes
should cause all ambiguous components to be shown. Apparently it does
the opposite (!)


Therefore - list-dirs-first breaks some cases and my solution breaks
others. Without both of them:

$ ls u/s*/a[tab]	note the asterisk after "s", i.e. any glob
No matches for: `files'


So, assuming list-dirs-first is simply broken (and it should only result
in different ordering of matches, completion of u/s*/a is apparently
some side effect only), what should be the correct way to complete

$ u/s*/a[tab]	into:
directory
share/aclocal/  share/atever/
files
sbin/a1         share/a1        share/a2

?


BTW this might be related to my previous thread:
"_complete: insert unambiguous when globbing"

-- 
Tomasz Pala <gotar@pld-linux.org>
-4500 s


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: cd /u/N/v/ tab expansion
  2022-04-10 14:32         ` Tomasz Pala
@ 2022-04-10 16:27           ` Tomasz Pala
  2022-04-10 16:32             ` Tomasz Pala
  2022-04-17  3:00           ` Bart Schaefer
  1 sibling, 1 reply; 20+ messages in thread
From: Tomasz Pala @ 2022-04-10 16:27 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: zsh-users

On Sun, Apr 10, 2022 at 16:32:22 +0200, Tomasz Pala wrote:

> This happens with: setopt glob_complete interfering with
[...]
> $ mkdir -p usr/{share/{aclocal,atever},sbin,src}
> $ touch usr/sbin/a1 usr/share/a1 usr/share/a2
> 
> $ ls u/s*/a[tab]
[...]
> 
> My solution was to use:
> 
> zstyle ':completion:*:*:*:*' list-suffixes yes
> 
> but then:
> 
> $ mkdir -p  a/{b1,b2}/d/{e1,e2}/g
> $ ls a/b/d/e/g[tab]
> No matches for: `files' or `directory'

I've tracked down this problem down to the initial commit:
https://sourceforge.net/p/zsh/code/ci/e0dc80e0e54df85329b1644001df80e908fd5b9c/

around line 745 of _path_files (currently), there is this code:

	if [[ -z "$listsfx" ]]; then
		[...]
	else
		[[ -n "$compstate[pattern_match]" ]] && SUFFIX="${SUFFIX:s./.*/}*"

this SUFFIX manglignt is required for:

$ ls u/s*/a[tab]	changes "/a" to "*/a*"

but it breaks
$ ls a/b/d/e/g[tab]	changing "/d/e/g" to "*/d/e/g*"


In both cases all the files ARE compadded properly, the problem emerges
from the leading and trailing asterisks added to the SUFFIX.

1. why the "*/d/e/g*" SUFFIX prevents completions from being used?
2. should it be left intact? What makes this *required* for u/s*/a?
3. if to be left intact - how to prevent this from happening? The only
difference I see are MATCH=/ MBEGIN=6 MEND=6.


The solution I've came works for me, but I got no idea why and if that's
even the rational way:

-	[[ -n "$compstate[pattern_match]" ]]			&& SUFFIX="${SUFFIX:s./.*/}*"
+	[[ -n "$compstate[pattern_match]" ]] && [ -z "$MATCH" ] && SUFFIX="${SUFFIX:s./.*/}*"



This code is full of hackery... "pws non-canonical hack", "A little
extra hack", "it should now be smart"...


-- 
Tomasz Pala <gotar@pld-linux.org>


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: cd /u/N/v/ tab expansion
  2022-04-10 16:27           ` Tomasz Pala
@ 2022-04-10 16:32             ` Tomasz Pala
  2022-04-10 17:45               ` Tomasz Pala
  0 siblings, 1 reply; 20+ messages in thread
From: Tomasz Pala @ 2022-04-10 16:32 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: zsh-users

On Sun, Apr 10, 2022 at 18:27:51 +0200, Tomasz Pala wrote:

> 3. if to be left intact - how to prevent this from happening? The only
> difference I see are MATCH=/ MBEGIN=6 MEND=6.
> 
> 
> The solution I've came works for me, but I got no idea why and if that's
> even the rational way:
> 
> -	[[ -n "$compstate[pattern_match]" ]]			&& SUFFIX="${SUFFIX:s./.*/}*"
> +	[[ -n "$compstate[pattern_match]" ]] && [ -z "$MATCH" ] && SUFFIX="${SUFFIX:s./.*/}*"

This doesn't work reliably... after first use MATCH is set and nothing
unsets it.

-- 
Tomasz Pala <gotar@pld-linux.org>


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: cd /u/N/v/ tab expansion
  2022-04-10 16:32             ` Tomasz Pala
@ 2022-04-10 17:45               ` Tomasz Pala
  2022-04-10 18:05                 ` Tomasz Pala
  0 siblings, 1 reply; 20+ messages in thread
From: Tomasz Pala @ 2022-04-10 17:45 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: zsh-users

Apparently compadd uses the $SUFFIX env behind the scene...

compadd -Qf -J argument-rest -X %Bfiles%b -J globbed-files \
	-M m:{a-z}={A-Z} -M m:{a-z}={A-Z} -p a/ -W a/	\
	-M r:|/=* r:|=* - b1/d/e2/g

...and THIS doesn't work with SUFFIX="*/d/e/g*" - therefore I did:


-             compadd "$tmp4[@]" $listopts - "$i"
+             compadd "$tmp4[@]" -U $listopts - "$i"


Actually I might have an idea why the original code doesn't work - see,
the "*/d/e/g*" is a pattern... that doesn't assume "e*" for "e2" part.

My original invocation wasn't a pattern, but "a/b/d/e/g" that was about
to be completed with the list-suffixes style as "containing multiple
partially typed pathname components"; however, the glob_complete sets
the compstate[pattern_match] which results in: "wildcard '*' is assumed at
the cursor position".

So, the correct solutions seem to be one of two (or maybe both):
1. either use the compadd -U flag as above or
2. properly mangle the SUFFIX (the 'g' global flag for substitution)

-            [[ -n "$compstate[pattern_match]" ]] && SUFFIX="${SUFFIX:s./.*/}*"
+            [[ -n "$compstate[pattern_match]" ]] && SUFFIX="${SUFFIX:gs./.*/}*"


The second solution doesn't play well with add-space style:

$ ls a/b/d/e/g[tab]
b1/d/e1/g/  b1/d/e2/g/  b2/d/e1/g/  b2/d/e2/g/

[ctrl-g]
$ ls a/b/d/e/g[tab]
$ ls a/b1/d/e1/ /g
               ^ cursor position
b1/d/e1/  b1/d/e2/  b2/d/e1/  b2/d/e2/

[ctrl-g]
$ ls a/b/d/e/g[tab]
b1/d/e1/g/  b1/d/e2/g/  b2/d/e1/g/  b2/d/e2/g/

and so on, over and over again.

$ zstyle -d :completion:\* add-space
$ ls a/b/d/e/g[tab]
$ ls a/b1/d/e1//g
b1/d/e1/  b1/d/e2/  b2/d/e1/  b2/d/e2/


Both of the solutions also seem to fix the list-dirs-first true issue!

-- 
Tomasz Pala <gotar@pld-linux.org>


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: cd /u/N/v/ tab expansion
  2022-04-10 17:45               ` Tomasz Pala
@ 2022-04-10 18:05                 ` Tomasz Pala
  2022-04-16 14:17                   ` Tomasz Pala
  0 siblings, 1 reply; 20+ messages in thread
From: Tomasz Pala @ 2022-04-10 18:05 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: zsh-users

On Sun, Apr 10, 2022 at 19:45:51 +0200, Tomasz Pala wrote:

> ...and THIS doesn't work with SUFFIX="*/d/e/g*" - therefore I did:
> 
> 
> -             compadd "$tmp4[@]" $listopts - "$i"
> +             compadd "$tmp4[@]" -U $listopts - "$i"

This with list-dirs-first has one issue:

$ ls u/s*/ax	-- cursor over 'a', tab menu cycling

[directories]
usr/share/aclocal/ x
usr/share/atever/ x
[files]
usr/sbin/a1
usr/share/a1
usr/share/a2

Note missing ' x' after completing files. Is that -U dropping the SUFFIX?

> 
> -            [[ -n "$compstate[pattern_match]" ]] && SUFFIX="${SUFFIX:s./.*/}*"
> +            [[ -n "$compstate[pattern_match]" ]] && SUFFIX="${SUFFIX:gs./.*/}*"
> 
> 
> The second solution doesn't play well with add-space style:
> 
> $ ls a/b/d/e/g[tab]
> b1/d/e1/g/  b1/d/e2/g/  b2/d/e1/g/  b2/d/e2/g/
> 
> [ctrl-g]
> $ ls a/b/d/e/g[tab]
> $ ls a/b1/d/e1/ /g
>                ^ cursor position
> b1/d/e1/  b1/d/e2/  b2/d/e1/  b2/d/e2/
> 
> [ctrl-g]
> $ ls a/b/d/e/g[tab]
> b1/d/e1/g/  b1/d/e2/g/  b2/d/e1/g/  b2/d/e2/g/
> 
> and so on, over and over again.

This cycling (ctrl-g toggling of behaviour) means something is not being
reset/unset properly and should be fixed.

However the latter case:

> $ zstyle -d :completion:\* add-space
> $ ls a/b/d/e/g[tab]
> $ ls a/b1/d/e1//g
> b1/d/e1/  b1/d/e2/  b2/d/e1/  b2/d/e2/

with cursor over first of "//" also differs from the first run (the
correct one).


This is caused by MBEGIN and MEND variables being set in both cases
(add-space and not). If they are about to be kept between the completion
invocations (even after the ctrl-c), they should not be used in
completion functions. Otherwise they should be cleared not to leak some
bogus state into consecutive invocations.

What is the purpose of MBEGIN and MEND?


> Both of the solutions also seem to fix the list-dirs-first true issue!

-- 
Tomasz Pala <gotar@pld-linux.org>


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: cd /u/N/v/ tab expansion
  2022-04-10 18:05                 ` Tomasz Pala
@ 2022-04-16 14:17                   ` Tomasz Pala
  0 siblings, 0 replies; 20+ messages in thread
From: Tomasz Pala @ 2022-04-16 14:17 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: zsh-users

Anyone on zsh-workers? If that was TL and DR, _path_files obviously
requires this change:

-            [[ -n "$compstate[pattern_match]" ]] && SUFFIX="${SUFFIX:s./.*/}*"
+            [[ -n "$compstate[pattern_match]" ]] && SUFFIX="${SUFFIX:gs./.*/}*"

and _might_ (not sure about this) work better with:

-             compadd "$tmp4[@]" $listopts - "$i"
+             compadd "$tmp4[@]" -U $listopts - "$i"



The following problem still exists, however it's apparently not
related to MBEGIN/MEND, needs more investigation.

On Sun, Apr 10, 2022 at 20:05:09 +0200, Tomasz Pala wrote:

>> $ ls a/b/d/e/g[tab]
>> b1/d/e1/g/  b1/d/e2/g/  b2/d/e1/g/  b2/d/e2/g/
>> 
>> [ctrl-g]
>> $ ls a/b/d/e/g[tab]
>> $ ls a/b1/d/e1/ /g
>>                ^ cursor position
>> b1/d/e1/  b1/d/e2/  b2/d/e1/  b2/d/e2/
>> 
>> [ctrl-g]
>> $ ls a/b/d/e/g[tab]
>> b1/d/e1/g/  b1/d/e2/g/  b2/d/e1/g/  b2/d/e2/g/
>> 
>> and so on, over and over again.
> 
> This cycling (ctrl-g toggling of behaviour) means something is not being
> reset/unset properly and should be fixed.
> 
> However the latter case:
> 
>> $ zstyle -d :completion:\* add-space
>> $ ls a/b/d/e/g[tab]
>> $ ls a/b1/d/e1//g
>> b1/d/e1/  b1/d/e2/  b2/d/e1/  b2/d/e2/
> 
> with cursor over first of "//" also differs from the first run (the
> correct one).
> 
> 
> This is caused by MBEGIN and MEND variables being set in both cases
[...]

-- 
Tomasz Pala <gotar@pld-linux.org>


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: cd /u/N/v/ tab expansion
  2022-04-10 14:32         ` Tomasz Pala
  2022-04-10 16:27           ` Tomasz Pala
@ 2022-04-17  3:00           ` Bart Schaefer
  2022-04-17 16:17             ` Tomasz Pala
  1 sibling, 1 reply; 20+ messages in thread
From: Bart Schaefer @ 2022-04-17  3:00 UTC (permalink / raw)
  To: Tomasz Pala; +Cc: Zsh Users

On Sun, Apr 10, 2022 at 7:32 AM Tomasz Pala <gotar@polanet.pl> wrote:
>
> On Sun, Apr 10, 2022 at 03:04:41 +0200, Tomasz Pala wrote:
>
> > $ cd /e/s/s/[tab]
> > No matches for: `directory'
>
> This happens with: setopt glob_complete interfering with
>
> zstyle ':completion:*' list-dirs-first true
>
> According to the docs this should not be correlated.

I am not able to reproduce this with zsh-5.8.1.2-test-9-g0ad3b11, at
least not with only:

zstyle '*' format %d
zstyle ':completion:*' list-dirs-first true
zstyle ':completion:*:*:*:*' list-suffixes yes
setopt globcomplete

> $ mkdir -p  a/{b1,b2}/d/{e1,e2}/g
> $ ls a/b/d/e/g[tab]
> No matches for: `files' or `directory'

This I am able to reproduce with the settings above.

However, if I invoke _next_tags at that point, I get:

% ls a/b/d/e/g
directory
b1/d/e/g  b2/d/e/g

So the results have been correctly completed and added, they're just
not in the tag group where they appear on the first attempt.

> This behaviour also doesn't match the docs - enabling list-suffixes
> should cause all ambiguous components to be shown. Apparently it does
> the opposite (!)

The settings of list-dirs-first and list-suffixes have no effect on
the tag to which the matches are added in this case.  It's all down to
globcomplete.  _next_tags works here, too.

When globcomplete is set, the following differences occur:
_path_files line 251 forces menu=yes
_path_files line 737 sets SUFFIX=*/d/e/g*
_path_files returns false to _files line 119, so ret=0 is not done at line 120
_files line 109 invokes _tags which calls comptags -N
_files returns false to _arguments, so ret=0 is not done at line 465
_arguments line 467 sets alwopt=yes
_arguments line 538 test is true, so 543-551 run compadd
_arguments line 586 is false, returns false to _dispatch, no ret=0 at line 63
_dispatch returns false to _complete, no ret=0 at line 117
_complete returns false _main_complete

As you mention in a later message on this this thread, one problem is
at _path_files line 737, that suffix will never match given that the
/e/ path segment is ambiguous.  Using :gs as you suggested resolves
everything after that, but introduces a new difference at
_main_compete:411, where compstate[pattern_match]='*' and
unambiguous_cursor=8 (instead of 4 in the noglobcomplete case).  That
seems to go along with having forced menu completion on, but it seems
odd.

Regarding:
> -             compadd "$tmp4[@]" $listopts - "$i"
> +             compadd "$tmp4[@]" -U $listopts - "$i"

Try ${Uopt} instead of -U there, and see if that makes any difference?

I don't seem to be able to re-create the setup for your "ctrl-g
toggling of behaviour" incident.  Can you specify?


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: cd /u/N/v/ tab expansion
  2022-04-17  3:00           ` Bart Schaefer
@ 2022-04-17 16:17             ` Tomasz Pala
  2022-04-17 18:15               ` Bart Schaefer
  2022-04-17 18:32               ` Bart Schaefer
  0 siblings, 2 replies; 20+ messages in thread
From: Tomasz Pala @ 2022-04-17 16:17 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh Users

On Sat, Apr 16, 2022 at 20:00:18 -0700, Bart Schaefer wrote:

>> > $ cd /e/s/s/[tab]
>> > No matches for: `directory'
>>
>> This happens with: setopt glob_complete interfering with
>>
>> zstyle ':completion:*' list-dirs-first true
> 
> I am not able to reproduce this with zsh-5.8.1.2-test-9-g0ad3b11, at
> least not with only:
> 
> zstyle '*' format %d
> zstyle ':completion:*' list-dirs-first true
> zstyle ':completion:*:*:*:*' list-suffixes yes
> setopt globcomplete

I might look for the other options involved if that matters, to provide
minimal config, however since you see the effect in scenario below I
guess the above one is only some compound side-effect (as this is also
fixed/masked by any of my 2 proposals, either "gs" or "-U").

>> $ mkdir -p  a/{b1,b2}/d/{e1,e2}/g
>> $ ls a/b/d/e/g[tab]
>> No matches for: `files' or `directory'
> 
> This I am able to reproduce with the settings above.
> 
> However, if I invoke _next_tags at that point, I get:
> 
> % ls a/b/d/e/g
> directory
> b1/d/e/g  b2/d/e/g
> 
> So the results have been correctly completed and added, they're just
> not in the tag group where they appear on the first attempt.

This is why "-U" alone also "fixes" my case as far as I understand (?).

> The settings of list-dirs-first and list-suffixes have no effect on
> the tag to which the matches are added in this case.  It's all down to
> globcomplete.  _next_tags works here, too.
> 
> When globcomplete is set, the following differences occur:
> _path_files line 251 forces menu=yes
> _path_files line 737 sets SUFFIX=*/d/e/g*
> _path_files returns false to _files line 119, so ret=0 is not done at line 120
> _files line 109 invokes _tags which calls comptags -N
> _files returns false to _arguments, so ret=0 is not done at line 465
> _arguments line 467 sets alwopt=yes
> _arguments line 538 test is true, so 543-551 run compadd
> _arguments line 586 is false, returns false to _dispatch, no ret=0 at line 63
> _dispatch returns false to _complete, no ret=0 at line 117
> _complete returns false _main_complete

This is far beyond my skills on completion flow tracking...

> As you mention in a later message on this this thread, one problem is
> at _path_files line 737, that suffix will never match given that the
> /e/ path segment is ambiguous.  Using :gs as you suggested resolves
> everything after that, but introduces a new difference at
> _main_compete:411, where compstate[pattern_match]='*' and
> unambiguous_cursor=8 (instead of 4 in the noglobcomplete case).  That
> seems to go along with having forced menu completion on, but it seems
> odd.

During some tests I did saw a 'weird' jumping of cursor from 'b'
position forward after a tab, just like the single disambiguation took
over and chosen both (AFAIR), but I didn't record the scenario.

> Regarding:
>> -             compadd "$tmp4[@]" $listopts - "$i"
>> +             compadd "$tmp4[@]" -U $listopts - "$i"
> 
> Try ${Uopt} instead of -U there, and see if that makes any difference?

I've already tried this without success.


> I don't seem to be able to re-create the setup for your "ctrl-g
> toggling of behaviour" incident.  Can you specify?

Sure, minimal config that exposes this "state-leaking":


setopt glob_complete

autoload -U compinit
compinit

zstyle ':completion:*' completer _complete _prefix
zstyle ':completion:*' add-space true
zstyle ':completion:*' menu select=long-list select=1
zstyle ':completion:*:*:*:*' list-suffixes yes


with _no_ "-U" added in _path_files (i.e. "-U" apparently fixes this one).
Note the 'add-space' style is optional, but enabled makes the problem
more viable ("toggleable").


With list-dirs-first working properly for "middle part ambiguosity" I
might simply disable the list-suffixes, however this is suspicious
itself to toggle results between consecutive completions.

best regards,
-- 
Tomasz Pala <gotar@pld-linux.org>


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: cd /u/N/v/ tab expansion
  2022-04-17 16:17             ` Tomasz Pala
@ 2022-04-17 18:15               ` Bart Schaefer
  2022-04-17 18:44                 ` Bart Schaefer
  2022-04-17 18:32               ` Bart Schaefer
  1 sibling, 1 reply; 20+ messages in thread
From: Bart Schaefer @ 2022-04-17 18:15 UTC (permalink / raw)
  To: Tomasz Pala; +Cc: Zsh Users

On Sun, Apr 17, 2022 at 9:17 AM Tomasz Pala <gotar@polanet.pl> wrote:
>
> On Sat, Apr 16, 2022 at 20:00:18 -0700, Bart Schaefer wrote:
>
> > I don't seem to be able to re-create the setup for your "ctrl-g
> > toggling of behaviour" incident.  Can you specify?
>
> Sure, minimal config that exposes this "state-leaking":
>
> setopt glob_complete

This is the trigger again, the other settings just make it possible to
see the difference.  I'm again suspicious of menu=yes being forced on
by _path_files for globcomplete.

On the first tab, menu completion is entered.  When you hit ctrl+g,
you exit menu completion, but do not exit/restart the ZLE editor.
That leaves $_lastcomp initialized, so when you hit tab again,
_main_complete line 83 sees that the word on the line has not changed
and therefore deliberately re-enters completion with the state from
the previous attempt.  Even though the command line shows the cursor
at the end of the word, the unambiguous_cursor position is used, which
splits the word into SUFFIX=/g and PREFIX=a/b/d/e and the rest of the
behavior follows from that.

The next ctrl+g has the same effect -- leaves menu completion but
leaves $_lastcomp alone -- so the behavior isn't really "toggling".
What's different on the third (and fifth, etc.) tab presses is that
the last trial completion ("a/b/d/e /g" with space) is no longer the
same as the word on the line ("a/b/d/e/g"), so _main_complete behaves
as if you've started a whole new completion, which generates the same
menu as the first tab.

The important part here is that it is not wrong (in most cases) to
re-enter completion with the preserved state when the word on the line
has not changed, so resetting _lastcomp is not the answer.

One possible fix is this:

diff --git a/Completion/Base/Core/_main_complete b/Completion/Base/Core/_main_co
mplete
index 169ca1f40..4ab572894 100644
--- a/Completion/Base/Core/_main_complete
+++ b/Completion/Base/Core/_main_complete
@@ -82,7 +82,8 @@ fi

 if [[ "$compstate[pattern_match]" = "*" &&
       "$_lastcomp[unambiguous]" = "$PREFIX" &&
-      -n "$_lastcomp[unambiguous_cursor]" ]]; then
+      -n "$_lastcomp[unambiguous_cursor]" &&
+      "$CURSOR" -eq "$_lastcomp[unambiguous_cursor]" ]]; then
   integer upos="$_lastcomp[unambiguous_cursor]"
   SUFFIX="$PREFIX[upos,-1]$SUFFIX"
   PREFIX="$PREFIX[1,upos-1]"

However, I'm concerned that will negatively affect behavior in other
circumstances, particularly when always_to_end is set or
complete_in_word is not set.

The question to be answered is whether Tomasz's expection that ctrl+g
will reset the state is correct, and if so, how to make that happen
when exiting menu completion that way.


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: cd /u/N/v/ tab expansion
  2022-04-17 16:17             ` Tomasz Pala
  2022-04-17 18:15               ` Bart Schaefer
@ 2022-04-17 18:32               ` Bart Schaefer
  1 sibling, 0 replies; 20+ messages in thread
From: Bart Schaefer @ 2022-04-17 18:32 UTC (permalink / raw)
  To: Tomasz Pala; +Cc: Zsh Users

On Sun, Apr 17, 2022 at 9:17 AM Tomasz Pala <gotar@polanet.pl> wrote:
>
> On Sat, Apr 16, 2022 at 20:00:18 -0700, Bart Schaefer wrote:
>
> > So the results have been correctly completed and added, they're just
> > not in the tag group where they appear on the first attempt.
>
> This is why "-U" alone also "fixes" my case as far as I understand (?).

If I'm following correctly, that prevents the internal completion
matching from removing what it thinks are non-matching entries from
the tag group.  That's why I'm a bit skeptical of unconditionally
passing -U, especially if the :gs change handles cases other than the
"state-leaking" (see previous response).

> This is far beyond my skills on completion flow tracking...

It's just running _complete_debug once with globcomplete off and again
with globcomplete on, and then diffing the trace files.  Plus some
idea of which deltas are meaningful.


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: cd /u/N/v/ tab expansion
  2022-04-17 18:15               ` Bart Schaefer
@ 2022-04-17 18:44                 ` Bart Schaefer
  0 siblings, 0 replies; 20+ messages in thread
From: Bart Schaefer @ 2022-04-17 18:44 UTC (permalink / raw)
  To: Tomasz Pala; +Cc: Zsh Users

On Sun, Apr 17, 2022 at 11:15 AM Bart Schaefer
<schaefer@brasslantern.com> wrote:
>
> The question to be answered is whether Tomasz's expection that ctrl+g
> will reset the state is correct, and if so, how to make that happen
> when exiting menu completion that way.

A correction:  It's exiting menu SELECTION with ctrl+g that is at issue.


^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2022-04-17 18:45 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-06 12:40 cd /u/N/v/ tab expansion zzapper
2022-04-07 20:11 ` Bart Schaefer
2022-04-07 20:20   ` zzapper
2022-04-07 23:11     ` Bart Schaefer
2022-04-08  9:53       ` zzapper
2022-04-08 17:57         ` Bart Schaefer
2022-04-08 10:22       ` david rayner
2022-04-08 18:09         ` Bart Schaefer
2022-04-10  1:04       ` Tomasz Pala
2022-04-10 14:32         ` Tomasz Pala
2022-04-10 16:27           ` Tomasz Pala
2022-04-10 16:32             ` Tomasz Pala
2022-04-10 17:45               ` Tomasz Pala
2022-04-10 18:05                 ` Tomasz Pala
2022-04-16 14:17                   ` Tomasz Pala
2022-04-17  3:00           ` Bart Schaefer
2022-04-17 16:17             ` Tomasz Pala
2022-04-17 18:15               ` Bart Schaefer
2022-04-17 18:44                 ` Bart Schaefer
2022-04-17 18:32               ` 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).