Re: WORDCHARS, etc.

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

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