_expand with dynamic named directories (and other issue)

_expand with dynamic named directories (and other issue)

[Mikael Magnusson]

~[foo]/<tab> with _expand in the completer style currently expands
~[foo] into whatever it expands into, and doesn't enter path
completion. It works correctly for ~/<tab> (eg, leaves the ~/ prefix
alone). Against my own better judgment I looked at _expand and found
out about keep-prefix. Setting that to 'true' indeed fixes the problem
I have, but it seems from the description that it should do what I
want when set to 'changed' as well. The code in the file doesn't make
it clear to me why the [foo] makes a difference.

The following is independent of _expand but ~[foo] tab discards the
brackets and just does named directory completion on foo, for example
expanding to ~foobar if that was a named directory. This may be
dependent on glob_complete to some degree, in that i don't get ~foobar
from ~[foo] without it set, but other weird things happen instead, for
example ~[cvids] turns into ~dl. If anything at this point, I would
either expect a / to be added or for it to expand into the full path
via _expand.

-- 
Mikael Magnusson

PATCH: One small step towards making ~[foo]<tab> work

[Mikael Magnusson]

I'm not sure if the first hunk does anything useful, because I'm unable
to make much else after that work yet. The second hunk at least makes it
so ~[foo/]/ tries ~[foo/] as the prefix instead of ~[foo. This results
in ~[m48/]<tab> completing to files inside the directory I want but,
it lists it as "corrections (errors: 1)". Doing ~[m48/]/<tab> produces a
"no match" error.

~[m48]<tab> still produces nonsense results like ~man ~messagebus etc,
I guess it thinks [m48] is a character class. I don't know where to hook
into that properly to redirect it to _path_files(?).

(The %%]*] is not strictly correct, zsh currently accepts
~[foo]blabla/hello as an expansion to bazblabla/hello if ~[foo] expands
to baz, which is possibly not something we should allow. It feels weird
anyway).

---
 Completion/Base/Completer/_expand | 1 +
 Completion/Unix/Type/_path_files  | 7 ++++++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/Completion/Base/Completer/_expand b/Completion/Base/Completer/_expand
index 3c76e13..1c25238 100644
--- a/Completion/Base/Completer/_expand
+++ b/Completion/Base/Completer/_expand
@@ -45,6 +45,7 @@ if [[ "$tmp" != (yes|true|on|1) ]]; then
   { [[ "$word" = \~(|[-+]) ||
        ( "$word" = \~[-+][1-9]## && $word[3,-1] -le $#dirstack ) ]] && return 1 }
   { [[ ( "$word" = \~* && ${#userdirs[(I)${word[2,-1]}*]}+${#nameddirs[(I)${word[2,-1]}*]} -gt 1 ) ||
+       ( "$word" = \~\[* ) ||
        ( "$word" = *\$[a-zA-Z0-9_]## && 
          ${#parameters[(I)${word##*\$}*]} -ne 1 ) ]] && continue=1 }
   [[ continue -eq 1 && "$tmp" != continue ]] && return 1
diff --git a/Completion/Unix/Type/_path_files b/Completion/Unix/Type/_path_files
index fc5bdac..f51db4a 100644
--- a/Completion/Unix/Type/_path_files
+++ b/Completion/Unix/Type/_path_files
@@ -283,7 +283,12 @@ elif [[ "$pre[1]" = \~ && -z "$compstate[quote]" ]]; then
   # paths and make sure that the loop below is run only once with an empty
   # prefix path by setting `prepaths'.
 
-  linepath="${pre[2,-1]%%/*}"
+  linepath="${pre[2,-1]}"
+  if [[ "$linepath" = \[* ]]; then
+    linepath="${linepath%%]*}]"
+  else
+    linepath="${linepath%%/*}"
+  fi
   if [[ -z "$linepath" ]]; then
     realpath="${HOME%/}/"
   elif [[ "$linepath" = ([-+]|)[0-9]## ]]; then
-- 
2.4.0

Re: PATCH: One small step towards making ~[foo]<tab> work

[Mikael Magnusson]

On Thu, Jun 18, 2015 at 1:28 PM, Mikael Magnusson <mikachu@gmail.com> wrote:
> I'm not sure if the first hunk does anything useful, because I'm unable
> to make much else after that work yet. The second hunk at least makes it
> so ~[foo/]/ tries ~[foo/] as the prefix instead of ~[foo. This results
> in ~[m48/]<tab> completing to files inside the directory I want but,
> it lists it as "corrections (errors: 1)". Doing ~[m48/]/<tab> produces a
> "no match" error.
>
> ~[m48]<tab> still produces nonsense results like ~man ~messagebus etc,
> I guess it thinks [m48] is a character class. I don't know where to hook
> into that properly to redirect it to _path_files(?).
>
> (The %%]*] is not strictly correct, zsh currently accepts
> ~[foo]blabla/hello as an expansion to bazblabla/hello if ~[foo] expands
> to baz, which is possibly not something we should allow. It feels weird
> anyway).

I realized my ~[foo] expansions where foo doesn't contain a / seem to
work pretty well, as long as you put the trailing slash after manually
(or completion puts it there for you), so there must be somewhere else
that doesn't know about the ~[foo] syntax in the completion code. Any
idea where that might be? I can live with ~[foo]<tab> not working for
now :). I can just invoke expand-word after all.

-- 
Mikael Magnusson

PATCH: Step two seems to take us there

[Mikael Magnusson]

This change on top of the previous one seems to make things work when
the foo in ~[foo] has a / in it. I'm not sick enough to try and make a \]
in there work.

Incidentally, it would be nice if the mail archive would include the
message-id so you can pass it to git-send-email's --in-reply-to without
looking it up in your own mail client. It does show the message-id for
the message it replies to, which seems less useful.

---
 Completion/Unix/Type/_path_files | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Completion/Unix/Type/_path_files b/Completion/Unix/Type/_path_files
index f51db4a..3a0ae43 100644
--- a/Completion/Unix/Type/_path_files
+++ b/Completion/Unix/Type/_path_files
@@ -321,8 +321,8 @@ elif [[ "$pre[1]" = \~ && -z "$compstate[quote]" ]]; then
   fi
   linepath="~${linepath}/"
   [[ "$realpath" = "$linepath" ]] && return 1
-  pre="${pre#*/}"
-  orig="${orig#*/}"
+  pre="${${pre#\~\[[^]]#]}#*/}"
+  orig="${${orig#\~\[[^]]#]}#*/}"
   donepath=
   prepaths=( '' )
 else
-- 
2.4.0

Re: PATCH: Step two seems to take us there

[Peter Stephenson]

On Sat, 20 Jun 2015 04:48:08 +0200
Mikael Magnusson <mikachu@gmail.com> wrote:
> This change on top of the previous one seems to make things work when
> the foo in ~[foo] has a / in it. I'm not sick enough to try and make a \]
> in there work.
>...
> -  pre="${pre#*/}"
> -  orig="${orig#*/}"
> +  pre="${${pre#\~\[[^]]#]}#*/}"
> +  orig="${${orig#\~\[[^]]#]}#*/}"
>...

You might want a backslash before the last "]".  (I think one works "to
guide the eye" but isn't necessary before the one after the "^".)

pws

Re: PATCH: Step two seems to take us there

[Mikael Magnusson]

On Sat, Jun 20, 2015 at 7:03 PM, Peter Stephenson
<p.w.stephenson@ntlworld.com> wrote:
> On Sat, 20 Jun 2015 04:48:08 +0200
> Mikael Magnusson <mikachu@gmail.com> wrote:
>> This change on top of the previous one seems to make things work when
>> the foo in ~[foo] has a / in it. I'm not sick enough to try and make a \]
>> in there work.
>>...
>> -  pre="${pre#*/}"
>> -  orig="${orig#*/}"
>> +  pre="${${pre#\~\[[^]]#]}#*/}"
>> +  orig="${${orig#\~\[[^]]#]}#*/}"
>>...
>
> You might want a backslash before the last "]".  (I think one works "to
> guide the eye" but isn't necessary before the one after the "^".)

That's probably a good idea, yeah. I noticed that I'm still getting
some "corrections: 1" with some completions, and I haven't been able
to figure out why yet. It happens even when my foo doesn't have a /
sometimes...

-- 
Mikael Magnusson