zsh-workers
 help / color / mirror / code / Atom feed
* PATCH: correctly breaking out of tag loops
@ 2017-11-01 21:01 Oliver Kiddle
  2017-11-09  3:36 ` Jun T
  0 siblings, 1 reply; 2+ messages in thread
From: Oliver Kiddle @ 2017-11-01 21:01 UTC (permalink / raw)
  To: Zsh workers

The tag-order style is not working for make completion to separate
targets from variables (with call-command set). It turns out that it is
not following the correct form for tag loops. The patch switches it to
using _alternative. _make also uses compadd -Q for targets which I can't
quite believe is correct but I'm not going to touch that.

I also searched for other instances of this and found a couple: in
_modutils and _zmodload.

Oliver

diff --git a/Completion/Linux/Command/_modutils b/Completion/Linux/Command/_modutils
index 5aa4c9cc7..9a37fcae1 100644
--- a/Completion/Linux/Command/_modutils
+++ b/Completion/Linux/Command/_modutils
@@ -119,6 +119,7 @@ _modutils() {
 	    while _tags; do
 		_requested files expl "module file"  _files -g '*.ko(-.)' && ret=0
 		_requested modules expl module compadd -a modules && ret=0
+		(( ret )) || break
 	    done
 	    ;;
 
diff --git a/Completion/Unix/Command/_make b/Completion/Unix/Command/_make
index a2ee9ecac..890ad1c83 100644
--- a/Completion/Unix/Command/_make
+++ b/Completion/Unix/Command/_make
@@ -287,14 +287,9 @@ _make() {
       compset -P 1 '*='
       _value "$@" && ret=0
     else
-      _tags targets variables
-      while _tags
-      do
-        _requested targets expl 'make targets' \
-          compadd -Q -- $TARGETS && ret=0
-        _requested variables expl 'make variables' \
-          compadd -S '=' -F keys -- ${(k)VARIABLES} && ret=0
-      done
+      _alternative \
+        'targets:make target:compadd -Q -a TARGETS' \
+        'variables:make variable:compadd -S = -F keys -k VARIABLES' && ret=0
     fi
   esac
 
diff --git a/Completion/Zsh/Command/_zmodload b/Completion/Zsh/Command/_zmodload
index 31163eb72..3416d50c6 100644
--- a/Completion/Zsh/Command/_zmodload
+++ b/Completion/Zsh/Command/_zmodload
@@ -72,6 +72,7 @@ else
       _files -W module_path -g '*.(dll|s[ol]|bundle)(:r)' && ret=0
     _requested aliases expl 'module alias' \
       compadd "$suf[@]" -k 'modules[(R)alias*]' && ret=0
+    (( ret )) || return 0
   done
   return ret
 fi


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

* Re: PATCH: correctly breaking out of tag loops
  2017-11-01 21:01 PATCH: correctly breaking out of tag loops Oliver Kiddle
@ 2017-11-09  3:36 ` Jun T
  0 siblings, 0 replies; 2+ messages in thread
From: Jun T @ 2017-11-09  3:36 UTC (permalink / raw)
  To: zsh-workers


> 2017/11/02 6:01, Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
> 
> . _make also uses compadd -Q for targets which I can't
> quite believe is correct but I'm not going to touch that.

I don’t remember exactly why I added -Q, but probably I wanted to
take care of the following cases:

GNU make allows glob chars * ? and [..,] to appear even in targets
(although I don’t understand when such targets are useful).
For example,

ch[1-4].pdf:  deps ...
	recipe

For this kind of targets, make does globbing by itself, so what this target
means depends on which of ch[1-4].pdf you already have. On the following
command line

zsh% make ch[1-4].pdf

zsh also need to expand ch[1-4].pdf to the list of files. If you quote it

zsh% make ch\[1-4\].pdf

then you will get "No rule to make target `c[1-4].dat’.” (if you have
at least one of ch[1-4].pdf).







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

end of thread, other threads:[~2017-11-09  4:17 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-01 21:01 PATCH: correctly breaking out of tag loops Oliver Kiddle
2017-11-09  3:36 ` Jun T

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