zsh-workers
 help / color / mirror / code / Atom feed
* match again
@ 2000-01-27 16:31 Andrej Borsenkow
  0 siblings, 0 replies; 11+ messages in thread
From: Andrej Borsenkow @ 2000-01-27 16:31 UTC (permalink / raw)
  To: ZSH workers mailing list

This does not work:

bor@itsrm2% patch -p0 --dry-run < /u/p/u/z/p/*/9441<TAB>

with settings

bor@itsrm2% compstyle -L
compstyle ':correct:' prompt 'correct to:'
compstyle ':approximate:' max-errors '3'
compstyle ':(correct|approximate):' max-errors '2' 'numeric'
compstyle '*:default' list-colors ''
compstyle '*:default' menu 'select=0'
compstyle '*:match' original 'yes'
compstyle '*:match' insert-unambiguous 'yes'
compstyle '*:paths' cursor 'yes'
compstyle '*:oldlist' list '_match'
compstyle ':*' verbose 'yes'
compstyle ':*' prefix-needed 'yes'
compstyle ':*' prefix-hidden 'no'
compstyle ':*' completer '_oldlist' '_complete' '_match'
compstyle ':*' tag-order 'arguments values' 'options' 'globbed-files'
'directories' 'all-files'

But this one does

bor@itsrm2% patch -p0 --dry-run <
/u2/pub/unix/zsh/patches/3.1.6-dev-16/<9440-><TAB>
bor@itsrm2% patch -p0 --dry-run < /u2/pub/unix/zsh/patches/3.1.6-dev-16/9441
9441   9442

/andrej


^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: match again
@ 2000-01-28 10:05 Sven Wischnowsky
  2000-01-28 16:47 ` Alexandre Duret-Lutz
  0 siblings, 1 reply; 11+ messages in thread
From: Sven Wischnowsky @ 2000-01-28 10:05 UTC (permalink / raw)
  To: zsh-workers


Andrej Borsenkow wrote:

> This does not work:
> 
> bor@itsrm2% patch -p0 --dry-run < /u/p/u/z/p/*/9441<TAB>
> 
> with settings
> 
> bor@itsrm2% compstyle -L
> compstyle ':correct:' prompt 'correct to:'
> ...

[ Time to use zstyle instead of compstyle (but maybe you just used it
for output?). ]

> 
> But this one does
> 
> bor@itsrm2% patch -p0 --dry-run <
> /u2/pub/unix/zsh/patches/3.1.6-dev-16/<9440-><TAB>
> bor@itsrm2% patch -p0 --dry-run < /u2/pub/unix/zsh/patches/3.1.6-dev-16/9441
> 9441   9442

I've already explained this at least twice. The problem is that the
completion code gets a PREFIX of the form f/*/b with
`compadd -p foo/baz/ - bar'. It tries to match `foo/baz/' with `f/*'
which doesn't work, because we can only either match the whole thing
with pattern matching (messing up braces and things) or do what we do
now, i.e. try to match the prefix (and suffix) normally and use
pattern matching for the strings (like `bar' in the example).

But we can try to make _path_files a bit cleverer... the patch below
makes it stop its ambiguous-part searching loop if it arrives at a
part with a pattern. It then changes the way the cursor style is
tested to hopefully give more sensible behaviour.

Andrej, is this, finally, acceptable for you?

Bye
 Sven

diff -ru ../z.old/Completion/Core/_path_files Completion/Core/_path_files
--- ../z.old/Completion/Core/_path_files	Fri Jan 28 10:23:55 2000
+++ Completion/Core/_path_files	Fri Jan 28 10:58:33 2000
@@ -172,7 +172,7 @@
 eorig="$orig"
 
 [[ $compstate[insert] = (*menu|[0-9]*) || -n "$_comp_correct" ||
-   ( $#compstate[pattern_match] -ne 0 &&
+   ( -n "$compstate[pattern_match]" &&
      "${orig#\~}" != "${${orig#\~}:q}" ) ]] && menu=yes
 
 # If given no `-F' option, we may want to use $fignore, turned into patterns.
@@ -442,7 +442,17 @@
       tmp4=( "${(@)tmp1:#${tmp1[1]}}" )
     fi
 
-    if (( $#tmp4 )); then
+    if [[ "$tpre" = */* ]]; then
+      PREFIX="${donepath}${linepath}${cpre}${tpre%%/*}"
+      SUFFIX="/${tsuf#*/}"
+    else
+      PREFIX="${donepath}${linepath}${cpre}${tpre}"
+      SUFFIX="${tsuf}"
+    fi
+
+    if (( $#tmp4 )) ||
+       [[ -n "$compstate[pattern_match]" &&
+          "$PREFIX$SUFFIX" != "${(q)PREFIX}${(q)SUFFIX}" ]]; then
 
       # It is. For menucompletion we now add the possible completions
       # for this component with the unambigous prefix we have built
@@ -451,29 +461,21 @@
       # collected as the suffixes to make the completion code expand
       # it as far as possible.
 
-      if [[ "$tpre" = */* ]]; then
-        PREFIX="${donepath}${linepath}${cpre}${tpre%%/*}"
-	SUFFIX="/${tsuf#*/}"
-      else
-        PREFIX="${donepath}${linepath}${cpre}${tpre}"
-	SUFFIX="${tsuf}"
-      fi
-
-      tmp4="$testpath"
-      compquote tmp1 tmp4
+      tmp2="$testpath"
+      compquote tmp1 tmp2
 
       if [[ -n $menu ]] ||
          ! zstyle -t ":completion${curcontext}:paths" expand suffix; then
-        zstyle -t ":completion${curcontext}:paths" cursor &&
+        (( $#tmp4 )) && zstyle -t ":completion${curcontext}:paths" cursor &&
             compstate[to_end]=''
         if [[ "$tmp3" = */* ]]; then
-	  compadd -Qf "$mopts[@]" -p "$linepath$tmp4" -s "/${tmp3#*/}" \
+	  compadd -Qf "$mopts[@]" -p "$linepath$tmp2" -s "/${tmp3#*/}" \
 	          -W "$prepath$realpath$testpath" \
 		  "$addpfx[@]" "$addsfx[@]" "$remsfx[@]" \
                   -M "r:|/=* r:|=* $mspec" "$group[@]" "$expl[@]" \
 		  - "${(@)tmp1%%/*}"
 	else
-	  compadd -Qf "$mopts[@]" -p "$linepath$tmp4" \
+	  compadd -Qf "$mopts[@]" -p "$linepath$tmp2" \
 	          -W "$prepath$realpath$testpath" \
 		   "$addpfx[@]" "$addsfx[@]" "$remsfx[@]" \
                    -M "r:|/=* r:|=* $mspec" "$group[@]" "$expl[@]" \
@@ -481,7 +483,7 @@
 	fi
       else
         if [[ "$tmp3" = */* ]]; then
-	  atmp=( -Qf "$mopts[@]" -p "$linepath$tmp4"
+	  atmp=( -Qf "$mopts[@]" -p "$linepath$tmp2"
 	         -W "$prepath$realpath$testpath"
 	         "$addpfx[@]" "$addsfx[@]" "$remsfx[@]"
                  -M "r:|/=* r:|=* $mspec" "$group[@]" "$expl[@]" )
@@ -489,7 +491,7 @@
 	    compadd "$atmp[@]" -s "/${i#*/}" - "${i%%/*}"
 	  done
         else
-	  compadd -Qf "$mopts[@]" -p "$linepath$tmp4" \
+	  compadd -Qf "$mopts[@]" -p "$linepath$tmp2" \
 		  -W "$prepath$realpath$testpath" \
 		  "$addpfx[@]" "$addsfx[@]" "$remsfx[@]" \
                   -M "r:|/=* r:|=* $mspec" "$group[@]" "$expl[@]" \

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de


^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: match again
@ 2000-01-31  9:06 Sven Wischnowsky
  2000-01-31 11:01 ` Bart Schaefer
  0 siblings, 1 reply; 11+ messages in thread
From: Sven Wischnowsky @ 2000-01-31  9:06 UTC (permalink / raw)
  To: zsh-workers


Bart Schaefer wrote:

> On Jan 28,  5:47pm, Alexandre Duret-Lutz wrote:
> } Subject: Re: match again
> }
> } -compstyle '*:options' prefix-hidden yes"
> } +zstyle '*:options' prefix-hidden yes"
> 
> (And several similar examples in comments.)
> 
> These are not equivalent.  Is it really correct to change it this way?
> The actual equivalent of the "compstyle" statement would be 
> 
> 	zstyle ':completion*:options' prefix-hidden yes

Right.

> While I'm on the topic, should there be a ':' before the '*' in that
> example?  One of the defaults installed by compinit itself comes out
> like 
> 	zstyle ':completion*:default' list-colors ...
> 
> whereas all the others resemble one of
> 
> 	zstyle :completion:correct: prompt 'correct to:'
> or
> 	zstyle ':completion:*' verbose yes
> 
> which makes me wonder if it should be
> 
> 	zstyle ':completion:*:default' list-colors ...
> 
> Clue me on the subtlety, please.

The problem is that the default tag is tested in _main_complete which
doesn't add a context name, so it is tested in the simple case as
`:completion:default', but when called from, e.g. _correct_word, as
`:completion:correct-word:default'. A nicer pattern would be
`:completion(|:*):default'.

This is the one place I don't like about the context names. One
solution would be to always stuff `:completion:' in front so that
there are two colons before the completer name, but then we would have 
those double colons not only before the command name (although this
may be not that big a problem).

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de


^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: match again
@ 2000-01-31  9:13 Sven Wischnowsky
  0 siblings, 0 replies; 11+ messages in thread
From: Sven Wischnowsky @ 2000-01-31  9:13 UTC (permalink / raw)
  To: zsh-workers


Alexandre Duret-Lutz wrote:

> compinit was still generating a ~/.zsh-styles using compstyle, 
> was it intentional?

Oops, no. Before the next official release we'll have to update
compconf() anyway. A ugly task, given the changes that were made to
the styles. I would much prefer to just remove compconf() and
compstyle() and let users who use 3.1.6 change their config stuff by
hand (at least compstyle() should be removed).

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de


^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: match again
@ 2000-01-31 13:01 Sven Wischnowsky
  2000-02-01 18:45 ` Peter Stephenson
  0 siblings, 1 reply; 11+ messages in thread
From: Sven Wischnowsky @ 2000-01-31 13:01 UTC (permalink / raw)
  To: zsh-workers


Bart Schaefer wrote:

> } The problem is that the default tag is tested in _main_complete which
> } doesn't add a context name
> 
> This seems an important point to me.  Is there a listing somewhere of
> the tags which are tested in _main_complete, or is "default" the only
> one?  At the least the doc for the default tag should mention this.

default and warnings (and the completer style is tested without tag at 
all). When I last cleanup up style/tag handling I mentioned that last
one, I think.

But, before we start modifying docs are something like this, I'd like
to repeat the question: would it be ok for everyone to make completer
names be preceeded by two colons? With that we could use this kind of
pattern:

> That means this example from the doc is wrong, does it not?
> 
>      To be able to share the same specifications one has set up for the
>      GNU version of the ls command one can use:
> 
>           zstyle ':completion:*:default' list-colors ${(s.:.)LS_COLORS}
>                              ^^^

... which is indeed wrong for the current state of the code. And I
really, really don't like having to use patterns like `:completion*:...'.
The only reason I didn't do that was because I had added the `::cmd:'
thing at that time already.

And: any suggestion for how to test the completer style with a tag?
Use the `default' tag (that just sounds weird, somehow, but maybe this 
is only my problem).

> BTW, I hope the intention is to put a lot more zstyle examples into the
> docs before final release.

Sure. Everyone is kindly invited to tell us about h(er|is) favorite
style settings. Ahem.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de


^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: match again
@ 2000-02-02  9:21 Sven Wischnowsky
  0 siblings, 0 replies; 11+ messages in thread
From: Sven Wischnowsky @ 2000-02-02  9:21 UTC (permalink / raw)
  To: zsh-workers


Peter Stephenson wrote:

> It looks better, but is it enough to sort out all possible cases where you
> might want to use `:*:'?  Or are there even more cases where we might get
> into trouble with that?  I'm worried we could be barking up the wrong tree,
> and should, for example, fix the fields of the pattern to
> e.g. :completion:completer:command-or-context:arguments:tag (this may not
> even be complete) with unrequired fields set to null strings but retaining
> the colons, so you can always guarantee to pick out the appropriate
> bit (unless there are extra colons inside the fields).  This will mean a
> lot of multiple colons, but I don't think that's a major problem (in fact,
> that's where we're heading anyway).
> 
> Any other uses of colons in the pattern --- e.g. to indicate a command name
> --- would have to be rethought, but replacing the second `:' by a `-' might
> be enough.  Or just have commands and other contexts specified in different
> fields (i.e. one is ...::command:... and the other ...:context::).
> 
> Probably the big headache would be enforcing consistency in the code as it
> stands --- virtually every use of styles would have to be rewritten.  But
> I like the idea that you can set `acontext=(${(s.:.)curcontext})' and pick
> a particular word of $acontext to check.

Yes, I'd like that, too -- and changing almost every function has been
done before. I don't think that we would need to change that many
functions anyway.

The problem is with `nested' completions a la `cvs add ...' where it
is very convenient to be able to stuff the `add' into the context
name, but maybe `cvs-add' is just as good. And in cases like
`find . -exec cvs add <TAB>' we probably don't need to have both
`find' and `cvs' in the final context name.

All this has been suggested before, btw (by Bart). He even suggested
using an array. I'd prefer to still use a simple string to make
testing and re-defining faster and cheaper, but if we don't use extra
fields for the `nested' cases above, it would be nice to be able to
access fields directly -- which suggests using a tied array at least
in those functions that modify some fields (instead of just
saving/restoring $curcontext or appending one of the basic name
components).

We may need another field: my suggested nslookup function sticks a
`:nslookup' after the `:completion' -- but maybe we don't really need
that. For things like the `cvs-add' above and the number of errors
accepted by correct and approximate using another separation character 
might be a good idea... opinions?

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de


^ permalink raw reply	[flat|nested] 11+ messages in thread
end of thread, other threads:[~2000-02-02  9:21 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-01-27 16:31 match again Andrej Borsenkow
2000-01-28 10:05 Sven Wischnowsky
2000-01-28 16:47 ` Alexandre Duret-Lutz
2000-01-30  1:27   ` Bart Schaefer
2000-02-01 10:48     ` Alexandre Duret-Lutz
2000-01-31  9:06 Sven Wischnowsky
2000-01-31 11:01 ` Bart Schaefer
2000-01-31  9:13 Sven Wischnowsky
2000-01-31 13:01 Sven Wischnowsky
2000-02-01 18:45 ` Peter Stephenson
2000-02-02  9:21 Sven Wischnowsky

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