From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6147 invoked from network); 20 Jun 1999 16:44:28 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 20 Jun 1999 16:44:28 -0000 Received: (qmail 15410 invoked by alias); 20 Jun 1999 16:44:16 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6729 Received: (qmail 15403 invoked from network); 20 Jun 1999 16:44:12 -0000 From: "Bart Schaefer" Message-Id: <990620164402.ZM14631@candle.brasslantern.com> Date: Sun, 20 Jun 1999 16:44:02 +0000 In-Reply-To: <9906201431.AA13678@ibmth.df.unipi.it> Comments: In reply to Peter Stephenson "Non-patch: zle argument handling" (Jun 20, 4:31pm) References: <9906201431.AA13678@ibmth.df.unipi.it> X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.auc.dk (Zsh hackers list) Subject: Re: Non-patch: zle argument handling MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jun 20, 4:31pm, Peter Stephenson wrote: } Subject: Non-patch: zle argument handling } } Here is what I think I've done: Sounds good to me. } Another possible suggestion: We could remove all the feep()'s from the code } and feep() if and only if the widget returned 1. I like this idea. } For user-defined widgets, we could have a special function to allow } them to feep and a special option to zle that will suppress the feep } for any other widget, so that simple zle -N's work without extra error } handling. I presume that in this scheme an un-suppressed feep() would abort the widget, as I believe currently happens? } (By the way, what does feep mean?) It means "failure beep." (Actually, it probably just means "beep", but I think some curses packages already have a beep() function so PF had to pick a different name.) } --- Doc/Zsh/builtins.yo.argdoc Thu Jun 17 16:53:03 1999 } +++ Doc/Zsh/builtins.yo Sun Jun 20 16:09:55 1999 } @@ -682,12 +682,15 @@ } With this flag set the return value is zero only if the character was } `tt(y)' or `tt(Y)'. Note that this always reads from the terminal, even } if used with the tt(-p) or tt(-u) or tt(-z) flags or with redirected input. } +May be called from a zle widget, in which case it will use zle to retrieve } +a key. } ) How about: With this flag set the return value is zero only if the character was `tt(y)' or `tt(Y)'. Note that this always reads from the terminal, even if used with the tt(-p) or tt(-u) or tt(-z) flags or with redirected input. +When called from a zle widget, zle is used to read from the terminal. However, I don't see what possible difference this makes, as only one key is read in any case, and it's still going to be interpreted as either `y' for `yes' or anything else for `no'. } item(tt(-k) [ var(num) ])( } Read only one (or var(num)) characters. All are assigned to the first } var(name), without word splitting. This flag is ignored when tt(-q) is } present. Input is read from the terminal unless one of tt(-u) or tt(-p) } -is present. } +is present. May be called from a zle widget with no tt(-u) } +or tt(-p) argument, in which case it will use zle to retrieve a key. } ) Does this imply when called from that var(num) is ignored and exactly one key is read regardless? That seems broken to me. If that's not what it means, then what difference does it make that zle is involved? Things should only get documented if they are visible behavior changes; and then what you need to document is the behavior, not the implementation. } +++ Doc/Zsh/zle.yo Sun Jun 20 16:27:38 1999 } @@ -102,6 +102,8 @@ } User-defined widgets, being implemented as shell functions, } can execute any normal shell command. They can also run other widgets } (whether built-in or user-defined) using the tt(zle) builtin command. } +They can use tt(read -k) or tt(read -q) to read characters from standard } +input, which will use the appropriate tt(zle) key input mechanism. } Finally, they can examine and edit the ZLE buffer being edited by } reading and setting the special parameters described below. Again, what does it *mean* to "use the appropriate key input mechanism"? Otherwise this stuff all looks great. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com