Re: WORDCHARS, etc.

[Wayne Davison <wayne@clari.net>]

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 <num>' 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 <num>
> 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..