zsh-workers
 help / color / mirror / code / Atom feed
* Re: _path_files and completeinword
@ 1999-03-10  9:44 Sven Wischnowsky
  1999-03-11 17:51 ` Andrej Borsenkow
  0 siblings, 1 reply; 4+ messages in thread
From: Sven Wischnowsky @ 1999-03-10  9:44 UTC (permalink / raw)
  To: zsh-workers


Andrej Borsenkow wrote:

> cp /t/s/z/D/zi
>              ^ cursor here (before `i')
> bor@itsrm2:~> cp /tools/src/zsh-3.1.5-pws-11/Doc/z<== cursor here; no `i'
> If I _now_ add `i' and do the same - I get zsh.texi

`_path_files' does the matching itself -- and sometimes things get too 
hard for it.
To allow `-g ...' patterns, it has to append these patterns to the
string from the line and then use that to generate filenames. Now you
might say that with `-f', no pattern is really needed. If you change:

  f)     sopt="${sopt}f"
         pats=("$pats[@]" '*')
	 ;;

to

  f)     sopt="${sopt}f"
         pats=("$pats[@]" '')
	 ;;

and

  if [[ -z "$gopt" ]]; then
    sopt='-f'
    pats=('*')

to

  if [[ -z "$gopt" ]]; then
    sopt='-f'
    pats=('')

you get what you expected. The same could be done for `-/' (this is
left as an exercise to the reader). I don't want to produce a patch
for this, though, because if we change it, the behavior will differ
from the behavior you get with things like `-g "*.(tex|TEX)"'. Here
the `*' in the pattern makes in-word completion fail in the way you
described.
Maybe this is another entry to the list of things I suggested the
`compstyle' parameter for.

> (I'm comparing to ways of life - how can I replace globcomplete. Is it
> possible to have the second binding with explcit globcomplete set? Sven, I
> think, it belongs to compstate as well. In this way I could have the second
> bindings that sets compstate[glob] and calls standard completion.

I'm not fully sure that I understand what you mean here. If you would
like to know if it possible to get a second key binding using the
completion code, but with `globcomplete'-behavior turned on, this is
simple:

- First solution: add a function

    _glob_complete() {
      compstate[pattern_match]=yes
      _main_complete
    }

  add a widget for it and bind that to a key. (Hey, you could get all
  this automatically by adding a file `_glob_complete' with the first
  line `#defkeycomp complete-word \C-xg' and the body above.)

- Second solution: modify your `_main_complete' by adding something
  like

    [[ $WIDGET = glob_complete ]] && compstate[pattern_match]=yes

  at the top. Then define a widget

    zle -C glob_complete complete-word _main_complete

  and that should do the job, too.

> Actually,
> I think, _all_ options that modify completion belong to compstate. The quick
> workaround is to save globcomplete, and reset it before exit, sure).

That's part of the things we are working on. I once had the idea to
make `compstate' get keys with the names of the options, but then
decided against it because some of them have multiple effects and I
wanted to do this in a cleaner way. Setting/resetting options in
cmpletion widgets, btw, will only seldom have an effect on the post-
processing, exactly for the reason, that this is now controlled by
`compstate'.


Bye
 Sven


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


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

* RE: _path_files and completeinword
  1999-03-10  9:44 _path_files and completeinword Sven Wischnowsky
@ 1999-03-11 17:51 ` Andrej Borsenkow
  0 siblings, 0 replies; 4+ messages in thread
From: Andrej Borsenkow @ 1999-03-11 17:51 UTC (permalink / raw)
  To: Sven Wischnowsky, zsh-workers

>
> `_path_files' does the matching itself -- and sometimes things get too
> hard for it.
> To allow `-g ...' patterns, it has to append these patterns to the
> string from the line and then use that to generate filenames.

Sorry? I don't understand it. The meaning of `-g'  is: "take as possible
matches the files that match given glob pattern(s)". The matches are only
*possible* - that is, they still have to match comand line to be included in
completion list.

If _path_files does something else, that means

 - it implements different completion as was always used in zsh
 - this is a bug

If we return to example (/t/s/z/D/z<CURSOR>i - implying
/tools/src/zsh-xxx/Doc/zsh.texi), then it means, that _path_files should
take a list of files in /tools/src/zsh-xxx/Doc that match given glob pattern
(let it be *.texi) and then match them against z*i.

/andrej



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

* RE: _path_files and completeinword
@ 1999-03-12  8:35 Sven Wischnowsky
  0 siblings, 0 replies; 4+ messages in thread
From: Sven Wischnowsky @ 1999-03-12  8:35 UTC (permalink / raw)
  To: zsh-workers


Andrej Borsenkow wrote:

> > `_path_files' does the matching itself -- and sometimes things get too
> > hard for it.
> > To allow `-g ...' patterns, it has to append these patterns to the
> > string from the line and then use that to generate filenames.
> 
> Sorry? I don't understand it. The meaning of `-g'  is: "take as possible
> matches the files that match given glob pattern(s)". The matches are only
> *possible* - that is, they still have to match comand line to be included in
> completion list.
> If _path_files does something else, that means
> 
>  - it implements different completion as was always used in zsh
>  - this is a bug
> 
> If we return to example (/t/s/z/D/z<CURSOR>i - implying
> /tools/src/zsh-xxx/Doc/zsh.texi), then it means, that _path_files should
> take a list of files in /tools/src/zsh-xxx/Doc that match given glob pattern
> (let it be *.texi) and then match them against z*i.

Well I never said that `_path_files' behaves exactly like
`comp{ctl,gen}', but maybe it should try harder...
I wanted to do everything in one step, making it fast, but after
trying it, I realised that supporting this doesn't make things too
slow.

Bye
 Sven

diff -u oc/Core/_path_files Completion/Core/_path_files
--- oc/Core/_path_files	Thu Mar 11 14:58:36 1999
+++ Completion/Core/_path_files	Fri Mar 12 09:32:32 1999
@@ -22,7 +22,7 @@
 
 local nm prepaths str linepath realpath donepath patstr prepath testpath rest
 local tmp1 collect tmp2 suffixes i ignore matchflags opt group sopt pats gopt
-local addpfx addsfx expl orig ostr nm=$compstate[nmatches] menu remsfx
+local addpfx addsfx expl orig ostr nm=$compstate[nmatches] menu remsfx patlast
 
 setopt localoptions nullglob rcexpandparam extendedglob
 unsetopt markdirs globsubst shwordsplit nounset
@@ -200,6 +200,25 @@
 
 patstr="$patstr:gs-/-*/-:gs/*.*./../:gs-/*.-/.-:gs/**/*/:gs-.*/-./-"
 
+# We take the last pathname component from the pattern and store it in
+# `patlast', replacing `*'s in it with patterns that match any character
+# but not slashes. Later we will generate matches using `patstr' with the
+# patterns we were given (like `*.c') appended to it, producing all matching
+# files. These filenames are then compared to `patlast' and all names not
+# matching that will be removed. All this is needed to be able to correctly
+# support `completeinword' as otherwise we would have something like `a*x'
+# from the line (the `*' was inserted above) and appending the `-g' pattern
+# `*.tex' would yield `a*x*.tex' which is not what we want.
+
+if [[ "$patstr" = */* ]]; then
+  patlast="*/${${patstr##*/}//\*/[^/]#}"
+  patstr="${patstr%/*}/"
+else
+  patlast="${patstr//\*/[^/]#}"
+  patstr=""
+fi
+
+
 # First we skip over all pathname components in `str' which really exist in
 # the file-system, so that `/usr/lib/l<TAB>' doesn't offer you `lib' and
 # `lib5'. Pathname components skipped this way are taken from `orig' and added
@@ -207,6 +226,7 @@
 
 while [[ "$orig" = */* ]] do
   tmp1=( ${~matchflags}$realpath$donepath${orig%%/*}/${~patstr#*/}$^pats )
+  tmp1=("${(@M)tmp1:#$~patlast}")
   [[ $#tmp1 -gt 0 && -e "$realpath$donepath${orig%%/*}" ]] || break
   donepath="$donepath${orig%%/*}/"
   orig="${orig#*/}"
@@ -261,6 +281,7 @@
 
       for i in "$tmp1[@]" ; do
         tmp2=( ${~i}/${~matchflags}${~suffixes} )
+        tmp2=("${(@M)tmp2:#$~patlast}")
         [[ $#tmp2 -ne 0 ]] && collect=( $collect $i )
       done
 
@@ -282,6 +303,7 @@
 	# Now produce all matching pathnames in `collect'.
 
         collect=( ${~collect}/${~matchflags}${~suffixes} )
+	collect=("${(@M)collect:#$~patlast}")
 
 	# And then remove the common path prefix from all these matches.
 
@@ -296,14 +318,14 @@
 
 	if [[ -n "$menu" ]]; then
           compadd -QU "$addpfx[@]" "$addsfx[@]" "$group[@]" "$expl[@]" \
-                  -i "$IPREFIX" -p "${linepath:q}${testpath:q}" \
+                  -i "$IPREFIX" -p "$linepath${testpath:q}" \
 		  -S "/${ostr#*/}" \
 		  -W "$tmp1" -f "$ignore[@]" - "${(@)${(@)collect%%/*}:q}"
 	else
           for i in $collect; do
-            compadd -U "$addpfx[@]" "$addsfx[@]" "$group[@]" "$expl[@]" \
-	            -i "$IPREFIX" -p "$linepath$testpath" -s "/${i#*/}" \
-		    -M 'r:|/=*' -W "$tmp1" -f "$ignore[@]" - "${i%%/*}"
+            compadd -QU "$addpfx[@]" "$addsfx[@]" "$group[@]" "$expl[@]" \
+	            -i "$IPREFIX" -p "$linepath${testpath:q}" -s "/${${i#*/}:q}" \
+		    -M 'r:|/=*' -W "$tmp1" -f "$ignore[@]" - "${${i%%/*}:q}"
           done
 	fi
 
@@ -337,6 +359,8 @@
   suffixes=( $str$^pats )
   suffixes=( "${(@)suffixes:gs.**.*.}" )
   tmp2=( ${~tmp1}${~matchflags}${~suffixes} )
+  tmp2=("${(@M)tmp2:#$~patlast}")
+
   if [[ $#tmp2 -eq 0 ]]; then
     # No match, insert the expanded path and add the original tail.
 
@@ -347,11 +371,11 @@
     [[ "$linepath$testpath$ostr" = "$PREFIX$SUFFIX" ]] && return 1
 
     compadd -QU -S '' "$group[@]" "$expl[@]" \
-            -i "$IPREFIX" -f - "${linepath:q}${testpath:q}$ostr"
+            -i "$IPREFIX" -f - "$linepath${testpath:q}$ostr"
   else
-    compadd -U "$addpfx[@]" "$addsfx[@]" "$remsfx[@]" "$group[@]" "$expl[@]" \
-            -i "$IPREFIX" -p "$linepath$testpath" -f "$ignore[@]" \
-	    -W "$prepath$realpath$testpath" - "${(@)tmp2#$tmp1}"
+    compadd -QU "$addpfx[@]" "$addsfx[@]" "$remsfx[@]" "$group[@]" "$expl[@]" \
+            -i "$IPREFIX" -p "$linepath${testpath:q}" -f "$ignore[@]" \
+	    -W "$prepath$realpath$testpath" - "${(@)${(@)tmp2#$tmp1}:q}"
   fi
 done
 

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


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

* _path_files and completeinword
@ 1999-03-09 16:28 Andrej Borsenkow
  0 siblings, 0 replies; 4+ messages in thread
From: Andrej Borsenkow @ 1999-03-09 16:28 UTC (permalink / raw)
  To: ZSH workers mailing list

cp /t/s/z/D/zi
             ^ cursor here (before `i')
bor@itsrm2:~> cp /tools/src/zsh-3.1.5-pws-11/Doc/z<== cursor here; no `i'
If I _now_ add `i' and do the same - I get zsh.texi

(I'm comparing to ways of life - how can I replace globcomplete. Is it
possible to have the second binding with explcit globcomplete set? Sven, I
think, it belongs to compstate as well. In this way I could have the second
bindings that sets compstate[glob] and calls standard completion. Actually,
I think, _all_ options that modify completion belong to compstate. The quick
workaround is to save globcomplete, and reset it before exit, sure).

cheers


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

end of thread, other threads:[~1999-03-12  8:35 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-03-10  9:44 _path_files and completeinword Sven Wischnowsky
1999-03-11 17:51 ` Andrej Borsenkow
  -- strict thread matches above, loose matches on Subject: below --
1999-03-12  8:35 Sven Wischnowsky
1999-03-09 16:28 Andrej Borsenkow

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