zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-workers@zsh.org
Subject: [PATCH] Proposed change to show-ambiguity context
Date: Sat, 16 May 2015 22:39:48 -0700	[thread overview]
Message-ID: <150516223948.ZM5746@torch.brasslantern.com> (raw)

The following patch moves the lookup of the show-ambiguity style from the
end of _main_complete (where the context is always tagless) into _setup
where the tags used for list-colors are examined.  This requires another
local to hang on to the desired color until after compadd has been called
to calculate the unambiguous prefix.

As mentioned in the comments added to _setup, really what we want is for
the most-specific of the list-colors or show-ambiguity context patterns
to be chosen, because at the time of colorizing the list the ZLS_COLORS
format used by show-ambiguity is always preferred over file-type colors.

(A possible way to achieve that would be to allow a list-colors value that
looks like e.g. "ambiguous=1;31" and do away with show-ambiguity.  However,
I haven't worked out all the ramifications of that.)

The patch at least allows one to choose to apply show-ambiguity in a more
restricted set of scopes.

Thoughts?


diff --git a/Completion/Base/Core/_main_complete b/Completion/Base/Core/_main_complete
index 977ab49..c023268 100644
--- a/Completion/Base/Core/_main_complete
+++ b/Completion/Base/Core/_main_complete
@@ -36,7 +36,8 @@ local func funcs ret=1 tmp _compskip format nm call match min max i num\
       _saved_list="${compstate[list]}" \
       _saved_insert="${compstate[insert]}" \
       _saved_colors="$ZLS_COLORS" \
-      _saved_colors_set=${+ZLS_COLORS}
+      _saved_colors_set=${+ZLS_COLORS} \
+      _ambiguous_color=''
 
 # _precommand sets this to indicate we are following a precommand modifier
 local -a precommands
@@ -349,12 +350,11 @@ elif [[ nm -eq 0 && -z "$_comp_mesg" &&
   compadd -x "$mesg"
 fi
 
-if zstyle -s ":completion:${curcontext}:" show-ambiguity tmp; then
-  local prefix=${${compstate[unambiguous]}[1,${compstate[unambiguous_cursor]}-1]}
+if [[ -n "$_ambiguous_color" ]]; then
   local toquote='[=\(\)\|~^?*[\]#<>]'
-  [[ $tmp = (yes|true|on) ]] && tmp=4
+  local prefix=${${compstate[unambiguous]}[1,${compstate[unambiguous_cursor]}-1]}
   [[ -n $prefix ]] &&
-    _comp_colors+=( "=(#i)${prefix[1,-2]//?/(}${prefix[1,-2]//(#m)?/${MATCH/$~toquote/\\$MATCH}|)}${prefix[-1]//(#m)$~toquote/\\$MATCH}(#b)(?|)*==$tmp" )
+    _comp_colors+=( "=(#i)${prefix[1,-2]//?/(}${prefix[1,-2]//(#m)?/${MATCH/$~toquote/\\$MATCH}|)}${prefix[-1]//(#m)$~toquote/\\$MATCH}(#b)(?|)*==$_ambiguous_color" )
 fi
 
 [[ "$_comp_force_list" = always ||
diff --git a/Completion/Base/Core/_setup b/Completion/Base/Core/_setup
index d85ebb8..ca97533 100644
--- a/Completion/Base/Core/_setup
+++ b/Completion/Base/Core/_setup
@@ -9,8 +9,7 @@ if zstyle -a ":completion:${curcontext}:$1" list-colors val; then
   if [[ "$1" = default ]]; then
     _comp_colors=( "$val[@]" )
   else
-    _comp_colors=( "$_comp_colors[@]"
-                   "(${2})${(@)^val:#(|\(*\)*)}" "${(M@)val:#\(*\)*}" )
+    _comp_colors+=( "(${2})${(@)^val:#(|\(*\)*)}" "${(M@)val:#\(*\)*}" )
   fi
 
 # Here is the problem mentioned in _main_complete.
@@ -23,6 +22,13 @@ elif [[ "$1" = default ]]; then
   unset ZLS_COLORS ZLS_COLOURS
 fi
 
+# What we'd like is to test that the show-ambiguity style pattern is more
+# specific than the list-colors style pattern, but that's not possible yet
+if zstyle -s ":completion:${curcontext}:$1" show-ambiguity val; then
+  zmodload -i zsh/complist
+  [[ $val = (yes|true|on) ]] && _ambiguous_color=4 || _ambiguous_color=$val
+fi
+
 if zstyle -t ":completion:${curcontext}:$1" list-packed; then
   compstate[list]="${compstate[list]} packed"
 elif [[ $? -eq 1 ]]; then


             reply	other threads:[~2015-05-17  5:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-17  5:39 Bart Schaefer [this message]
2015-05-17 23:45 ` Daniel Shahaf
2015-05-18  4:03   ` Bart Schaefer
2015-05-19  1:51     ` Daniel Shahaf
2015-05-19  3:09       ` Bart Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=150516223948.ZM5746@torch.brasslantern.com \
    --to=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).