zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh workers <zsh-workers@zsh.org>
Subject: Re: using the description from _arguments foo:description:->state
Date: Sun, 11 Sep 2011 11:10:50 -0700	[thread overview]
Message-ID: <110911111050.ZM11625@torch.brasslantern.com> (raw)
In-Reply-To: <CAHYJk3RA-o47Lwtv-5tGgzQnKz1voKz93bGvLuZdgT07hacSng@mail.gmail.com>

On Sep 11,  5:04pm, Mikael Magnusson wrote:
}
}  "($opts)-A[define widget alias]:old widget:->widget :new widget:->widget"
} 
} Is there any way to get that description from the $state handler and
} pass it on to compadd?

It appears the answer to this is categorically "no."

The description is extracted into the $descrs array by the comparguments
builtin called at _arguments line 318.  It's then assigned to $descr at
line 355 and passed through to _description for formatting at line 366.

However, all of the related variables are declared local to _arguments,
so when that eventually returns without ever making a call to compadd,
all that information is discarded.

Given the usual state (ahem) of the _arguments code, it's surprisingly
straightforward to add a parallel array for passing back the description:


Index: Completion/Base/Utility/_arguments
===================================================================
*** Completion/Base/Utility/_arguments	23 Nov 2008 18:26:27 -0000
--- Completion/Base/Utility/_arguments	11 Sep 2011 17:44:45 -0000
***************
*** 344,349 ****
--- 344,350 ----
  
    context=()
    state=()
+   state_descr=()
  
    while true; do
      while _tags; do
***************
*** 376,381 ****
--- 377,383 ----
  	      if (( ! $state[(I)$action] )); then
                  comparguments -W line opt_args
                  state+=( "$action" )
+                 state_descr+=( "$descr" )
  	        if [[ -n "$usecc" ]]; then
  	          curcontext="${oldcontext%:*}:$subc"
  	        else

(Not sure why the use of tabs for indentation is different on adjacent
lines in that section of _arguments.)

However, because callers of _arguments are responsible for declaring
state as a local, there are a HUGE number of files that would have to
be updated to also declare state_descr as a local ... UNLESS we were
willing to declare it local in _main_complete as is done with the
opt_args variable (which is also supposed to be declared local by all
callers of _arguments but conspicuously is not by several completers
including _zle).

Also I'm not really happy with "state_descr" as a name, but I suppose
it'll do.  Anyway then we have:

Index: Completion/Zsh/Command/_zle
===================================================================
--- Completion/Zsh/Command/_zle	21 Dec 2010 16:41:15 -0000
+++ Completion/Zsh/Command/_zle	11 Sep 2011 17:57:16 -0000
@@ -44,7 +44,7 @@
       '(-)*:widget arguments: ' && ret=0
     ;;
   (widget*)
-    _wanted -C "$context[1]" widgets expl widget compadd -k widgets && ret=0
+    _wanted -C "$context[1]" widgets expl "${state_descr[1]:-widget}" compadd -k widgets && ret=0
     ;&
   (function)
     [[ $state[1] != *function ]] ||	# Handle fall-through


Index: Completion/Base/Core/_main_complete
===================================================================
--- Completion/Base/Core/_main_complete	1 Jun 2011 06:39:59 -0000
+++ Completion/Base/Core/_main_complete	11 Sep 2011 17:59:57 -0000
@@ -23,7 +23,8 @@
 local func funcs ret=1 tmp _compskip format nm call match min max i num\
       _completers _completer _completer_num curtag _comp_force_list \
       _matchers _matcher _c_matcher _matcher_num _comp_tags _comp_mesg  \
-      mesg str context state line opt_args val_args curcontext="$curcontext" \
+      mesg str context state state_descr line opt_args val_args \
+      curcontext="$curcontext" \
       _last_nmatches=-1 _last_menu_style _def_menu_style _menu_style sel \
       _tags_level=0 \
       _saved_exact="${compstate[exact]}" \

And for completeness (ahem):

Index: Completion/Base/Utility/_values
===================================================================
RCS file: /extra/cvsroot/zsh/zsh-4.0/Completion/Base/Utility/_values,v
retrieving revision 1.9
diff -c -r1.9 _values
--- Completion/Base/Utility/_values	21 Dec 2010 16:41:15 -0000	1.9
+++ Completion/Base/Utility/_values	11 Sep 2011 18:06:27 -0000
@@ -87,6 +87,7 @@
   if [[ "$action" = -\>* ]]; then
     compvalues -v val_args
     state="${${action[3,-1]##[ 	]#}%%[ 	]#}"
+    state_descr="$descr"
     if [[ -n "$usecc" ]]; then
       curcontext="${oldcontext%:*}:$subc"
     else

Opinions?

-- 
Barton E. Schaefer


  reply	other threads:[~2011-09-11 18:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-11 15:04 Mikael Magnusson
2011-09-11 18:10 ` Bart Schaefer [this message]
2011-09-20 15:16   ` Mikael Magnusson
2011-09-21 11:39     ` Oliver Kiddle
2011-09-21 15:50       ` Bart Schaefer
2011-09-21 17:10         ` Oliver Kiddle
2011-09-22  4:04           ` 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=110911111050.ZM11625@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).