[PATCH] Proposed change to show-ambiguity context

[PATCH] Proposed change to show-ambiguity context

[Bart Schaefer]

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

Re: [PATCH] Proposed change to show-ambiguity context

[Daniel Shahaf]

Bart Schaefer wrote on Sat, May 16, 2015 at 22:39:48 -0700:
> 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.
> 

I always wondered list-colors and LS_COLORS were either/or, rather than
overlay list-colors on top of LS_COLORS — that is: have the already-typed
part of the filename in color X, the next-letter-to-be-typed in color Y,
and the remainder of the filename colored according to LS_COLORS.  (where
X and Y are specified by list-colors/show-ambiguity)

> (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?

Re: [PATCH] Proposed change to show-ambiguity context

[Bart Schaefer]

On May 17, 11:45pm, Daniel Shahaf wrote:
}
} I always wondered list-colors and LS_COLORS were either/or, rather than
} overlay list-colors on top of LS_COLORS - that is: have the already-typed
} part of the filename in color X, the next-letter-to-be-typed in color Y,
} and the remainder of the filename colored according to LS_COLORS.  (where
} X and Y are specified by list-colors/show-ambiguity)

Because list-colors and show-ambiguity, like most of the "menu" styles,
are just alternate interfaces to the base functionality from complist. as
implemented by LS_COLORS, et al.

The zstyle mechanism is not interpreted anywhere internally, it's just
a different namespace for storing things and looking them up.

Re: [PATCH] Proposed change to show-ambiguity context

[Daniel Shahaf]

Bart Schaefer wrote on Sun, May 17, 2015 at 21:03:36 -0700:
> On May 17, 11:45pm, Daniel Shahaf wrote:
> }
> } I always wondered list-colors and LS_COLORS were either/or, rather than
> } overlay list-colors on top of LS_COLORS - that is: have the already-typed
> } part of the filename in color X, the next-letter-to-be-typed in color Y,
> } and the remainder of the filename colored according to LS_COLORS.  (where
> } X and Y are specified by list-colors/show-ambiguity)
> 
> Because list-colors and show-ambiguity, like most of the "menu" styles,
> are just alternate interfaces to the base functionality from complist. as
> implemented by LS_COLORS, et al.
> 

So you're saying, it's this way because down in ZLS_COLORS, the "pattern
matching" form is filetype-agnostic and has precedence over the
"per-filetype" form.  Thanks for the pointer.

P.S. As to your actual question in this thread, I have no opinion, as
I don't use show-ambiguity, but list-colors directly, and AIUI the patch
doesn't change the semantics of list-colors.

Re: [PATCH] Proposed change to show-ambiguity context

[Bart Schaefer]

On May 19,  1:51am, Daniel Shahaf wrote:
}
} So you're saying, it's this way because down in ZLS_COLORS, the "pattern
} matching" form is filetype-agnostic and has precedence over the
} "per-filetype" form.  Thanks for the pointer.

Well, that, and also that underneath there is only one ZLS_COLORS; the
zstyles for list-colors and show-ambiguity are both just other ways to
set the value of ZLS_COLORS.  (I typo'd LS_COLORS where I meant ZLS in
my previous answer.)