From: Peter Stephenson <pws@ibmth.df.unipi.it>
To: zsh-workers@sunsite.auc.dk (Zsh hackers list)
Subject: Re: WORDCHARS, etc.
Date: Sat, 12 Jun 1999 17:41:23 +0200 [thread overview]
Message-ID: <9906121541.AA35258@ibmth.df.unipi.it> (raw)
In-Reply-To: "Sven Wischnowsky"'s message of "Thu, 10 Jun 1999 12:42:44 DFT." <199906101042.MAA23616@beta.informatik.hu-berlin.de>
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. We could than probably have a couple of generic
> functions (e.g. for word movement) and define aliases to them with
> fixed arguments (as Peter suggested with flags), probably even for
> some of the functions that are currently real builtin widgets.
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? (Wayne, how does your patch for `zle widget <num>' work? It
seems to assume it should set the digit argument to 1 if <num> didn't
begin with a digit. Is that important? And shouldn't it handle negative
numbers?) There's no way of telling whether an arbitrary widget wants a
digit or a string; should be add a flag for the latter?
- 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. 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. Where would more than one
argument be useful (apart from specifying a numeric as well as a string
argument)?
- 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.
--
Peter Stephenson <pws@ibmth.df.unipi.it> Tel: +39 050 844536
WWW: http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy
next parent reply other threads:[~1999-06-12 16:10 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 [this message]
1999-06-13 6:53 ` Wayne Davison
1999-06-13 11:17 ` Bart Schaefer
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=9906121541.AA35258@ibmth.df.unipi.it \
--to=pws@ibmth.df.unipi.it \
--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).