zsh-workers
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <opk@u.genie.co.uk>
To: Zsh workers <zsh-workers@sunsite.auc.dk>
Subject: PATCH: New _read and selective parameter completion
Date: Wed, 09 Aug 2000 21:10:51 +0100	[thread overview]
Message-ID: <3991BACB.33692F9@u.genie.co.uk> (raw)

This adds an _arguments based completion function for read. I don't think
we have too many builtins left where conversion to use _arguments would
still be useful. Any requests?       

I thought about modifying _vars to insert the '[' for arrays and
associations but _parameters would first need to be given an option to
make it only complete specific types of parameter. Would anyone object
to my adding this? I was thinking of a -g option (analogous to the -g
option of _files) where the pattern specified would be augmented with
~*local* and used to match the values in the $parameters association.

I mentioned this vaguely before in 11284 and Sven had some good ideas
in his reply (11293). The focus there is more towards having the
patterns configurable via a style similar to the file-patterns tag but
my suggested option would I think be a useful first step.

Oliver

Index: Completion/Builtins/_read
===================================================================
RCS file: _read
diff -N _read
--- /dev/null	Tue May  5 13:32:27 1998
+++ _read	Wed Aug  9 14:09:15 2000
@@ -0,0 +1,18 @@
+#compdef read
+
+local pflag expl line curcontext="$curcontext"
+
+# -p flag only relevant if we have a coprocess
+(:>&p) 2>/dev/null &&
+  pflag='(-q -u -z)-p[input is read from the coprocess]'
+
+_arguments -C -s \
+  '-r[raw mode]' \
+  '(-p -k -u -z)-q[read y or n character from terminal]' \
+  '(-q)-k[specify number of characters to read]:number of characters' \
+  '(-q -u -p)-z[read entry from editor buffer stack]' \
+  '(-E)-e[input read is echoed and not assigned]' \
+  '(-e)-E[input read is echoed]' \
+  '-A[first name is taken as an array]' \
+  '(-q -z -p)-u+[specify file-descriptor to read from]:file-descriptor:_file_descriptors' \
+  $pflag '1:varprompt:_vars -qS\?' '*:vars:_vars'
Index: Completion/Builtins/_vars
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Builtins/_vars,v
retrieving revision 1.3
diff -u -r1.3 _vars
--- Completion/Builtins/_vars	2000/05/31 09:38:26	1.3
+++ Completion/Builtins/_vars	2000/08/09 21:09:15
@@ -1,4 +1,4 @@
-#compdef getopts read unset vared
+#compdef getopts unset vared
 
 # This will handle completion of keys of associative arrays, e.g. at
 # `vared foo[<TAB>'.  However, in this version the [ must be added
@@ -20,5 +20,5 @@
         compadd $addclose -k "$var"
   fi
 else
-  _parameters
+  _parameters "$@"
 fi


             reply	other threads:[~2000-08-09 21:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-08-09 20:10 Oliver Kiddle [this message]
2000-08-14  7:08 ` Andrej Borsenkow
2000-08-10  7:08 Sven Wischnowsky

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=3991BACB.33692F9@u.genie.co.uk \
    --to=opk@u.genie.co.uk \
    --cc=zsh-workers@sunsite.auc.dk \
    /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).