zsh-workers
 help / color / mirror / code / Atom feed
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


       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).