From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8917 invoked from network); 13 Jun 1999 06:54:09 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 13 Jun 1999 06:54:09 -0000 Received: (qmail 5692 invoked by alias); 13 Jun 1999 06:54:04 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6603 Received: (qmail 5685 invoked from network); 13 Jun 1999 06:54:04 -0000 Date: Sat, 12 Jun 1999 23:53:57 -0700 (PDT) From: Wayne Davison To: Peter Stephenson cc: Zsh hackers list Subject: Re: WORDCHARS, etc. In-Reply-To: <9906121541.AA35258@ibmth.df.unipi.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 12 Jun 1999, Peter Stephenson wrote: > - How do we decide whether an argument is going to be a digit > argument or a string? If we're going to start allowing arbitrary arguments to be specified then we need some kind of option syntax so we can set either or both args for a function. How about adding the -n# option to set an actual value, and the -N option to set the number as unspecified (i.e. "use the default"). For instance: zle up-line -n 5 # goes up 5 lines, restores numeric arg afterward zle up-line # goes up current-numeric-arg # of lines zle up-line -N # goes up default # of lines, restores numeric arg zle vi-fetch-history -N # goes to last history event zle vi-fetch-history -n3847 # goes to history event 3847 What do you think? > (Wayne, how does your patch for `zle widget ' work? Since there is currently no non-numeric-argument support in the zle, my code just assumed that an optional trailing arg wanted to affect the numeric arg. If no arg is specified, it assumes that the command should use the current value of the numeric arg. It also assumes that a non-numeric value will override the current numeric arg into the arg-wasn't-specified state. > It seems to assume it should set the digit argument to 1 if > didn't begin with a digit. Is that important? Yes. Most zle functions default to 1 if no argument is specified, so the zle code allows functions to be lazy about doing a proper arg check: any function that defaults to 1 can simply use the value of zmult and it will be right. For those unusual functions that default to a different value, they first check if an actual arg was present (if MOD_MULT was set in the flags), and only use zmult if it is a real value. > And shouldn't it handle negative numbers?) Yes, it certainly should -- looks like I missed that. > - Then we presumably need to add two flags, saying whether the > command just expects typed input, like isearches (which will be > treated like bindkey -s strings and put into the unget buffer), > or whether it actually wants a string argument, like the > proposed modifications to the movement commands. Alternately, current commands like isearch can be tweaked to look for a string arg and only read the keyboard if no string input was specified. > Where would more than one argument be useful (apart from > specifying a numeric as well as a string argument)? Maybe we should just keep the trailing argument(s) (sans any -n/-N parsing) as a single string and let the command choose to parse it as it sees fit (some commands may wish to break up the string using whitespace, and some may not). ..wayne..