From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: Peter Stephenson <pws@ibmth.df.unipi.it>,
zsh-workers@sunsite.auc.dk (Zsh hackers list),
Wayne Davison <wayne@clari.net>
Subject: Re: WORDCHARS, etc.
Date: Sun, 13 Jun 1999 11:17:20 +0000 [thread overview]
Message-ID: <990613111720.ZM14111@candle.brasslantern.com> (raw)
In-Reply-To: <9906121541.AA35258@ibmth.df.unipi.it>
In-Reply-To: <Pine.GSO.4.10.9906122308380.26180-100000@house.clari.net>
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
next prev parent reply other threads:[~1999-06-13 11:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <199906101042.MAA23616@beta.informatik.hu-berlin.de>
1999-06-12 15:41 ` Peter Stephenson
1999-06-13 6:53 ` Wayne Davison
1999-06-13 11:17 ` Bart Schaefer [this message]
1999-06-14 7:15 ` Peter Stephenson
1999-06-14 9:19 Sven Wischnowsky
1999-06-14 14:42 ` Peter Stephenson
1999-06-14 13:12 Sven Wischnowsky
1999-06-15 6:57 Sven Wischnowsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=990613111720.ZM14111@candle.brasslantern.com \
--to=schaefer@candle.brasslantern.com \
--cc=pws@ibmth.df.unipi.it \
--cc=wayne@clari.net \
--cc=zsh-workers@sunsite.auc.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).