From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16615 invoked from network); 13 Jun 1999 11:17:59 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 13 Jun 1999 11:17:59 -0000 Received: (qmail 20331 invoked by alias); 13 Jun 1999 11:17:36 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6605 Received: (qmail 20324 invoked from network); 13 Jun 1999 11:17:33 -0000 From: "Bart Schaefer" Message-Id: <990613111720.ZM14111@candle.brasslantern.com> Date: Sun, 13 Jun 1999 11:17:20 +0000 In-Reply-To: <9906121541.AA35258@ibmth.df.unipi.it> Comments: In reply to Peter Stephenson "Re: WORDCHARS, etc." (Jun 12, 5:41pm) References: <9906121541.AA35258@ibmth.df.unipi.it> In-Reply-To: Comments: In reply to Wayne Davison "Re: WORDCHARS, etc." (Jun 12, 11:53pm) X-Mailer: Z-Mail (5.0.0 30July97) To: Peter Stephenson , zsh-workers@sunsite.auc.dk (Zsh hackers list), Wayne Davison Subject: Re: WORDCHARS, etc. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jun 12, 5:41pm, Peter Stephenson wrote: } Subject: Re: WORDCHARS, etc. } } Sven Wischnowsky wrote: } > The more I read about this the more I think that we should just go } > ahead and allow all zle widget functions to get (an arbitrary number } > of) arguments (strings). If no arguments are given, the function uses } > its defaults. } } Just thinking about this again. I've moved the discussion to zsh-workers. } } - How do we decide whether an argument is going to be a digit argument or a } string? I suggest they simply always be strings and let the function parse them as it wants. If what's wanted is only to change the numeric argument, one can always use a little wrapper function that sets NUMERIC. Which reminds me to again repeat my bug report from 4099: zagzig<1> fnord() { zle digit-argument ; BUFFER="$BUFFER $NUMERIC" } zagzig<2> zle -N fnord zagzig<3> bindkey '^X^F' fnord zagzig<4> 1 6 66 666 6666 66666 666666 6666666 66666666 666666666 -1923267926 (the last line comes from repeatedly hitting ^X^F). Back on the original topic, the string arguments can be passed to user- defined widget functions as $argv. Probably there's an analogous way that built-ins can get at them. BTW, have you looked at zsh-workers/4098 and 4101 lately? The advent of NUMERIC has made bits of 4098 moot, but it shows how to pass arguments to widget functions. Works great; I've been merging it into every -pws-N release for my private use as the code around it changes, so I could give you an updated patch quite easily. } - 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 Hmm; here you're talking about built-in widgets rather than user-defined ones, right? I think we should define a convention used by the built-ins for parsing the string arguments and simply tell people (in the manual) that the Right Thing to do is to write their widget functions to follow the same conventions. } If you think it's useful to have more than one } argument, then presumably a counter giving the max number of string } arguments is more useful than a second flag. That counter is called $#, obviously ... } Where would more than one } argument be useful (apart from specifying a numeric as well as a string } argument)? Isn't that tantamount to asking "When is &optional useful in elisp?" Suppose I want to write a widget that takes three arguments: a command name to search the history for, a word in the resulting command line that I want to change, and the new word that I want to change it to. Are you really going to make me parse all that out of a single string myself when zsh could easily set $1 $2 $3 for me? } - The extended alias mechanism, if it's a good idea, would presumably allo } `zle -A old-widget new-widget args-to-pass-to-old-widget'. Then you can } create, for example, an ad hoc isearch command with just a zle -A command } without needing to define a function. That would mean adding room for } either a char * or a char ** or a LinkList in the thingy struct, though. I don't think it's necessary to extend the alias mechanism like that. It should be sufficient to write: zle -A old-widget renamed-old-widget new-widget() { zle renamed-old-widget args-to-pass-to-old-widget } zle -N old-widget new-widget On Jun 12, 11:53pm, Wayne Davison wrote: } Subject: Re: WORDCHARS, etc. } } 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? This seems like a fine convention for my suggestion above. We need more, of course, like maybe: `-I string' means interpret `string' as if it were typed input; and so on. } 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. That's an equally good (I think even better) idea. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com