zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <pws@ibmth.df.unipi.it>
To: zsh-workers@sunsite.auc.dk
Subject: Re: PATCH: 3.1.5-pws-8: using pattern completions
Date: Fri, 19 Feb 1999 15:53:31 +0100	[thread overview]
Message-ID: <9902191453.AA11538@ibmth.df.unipi.it> (raw)
In-Reply-To: "Sven Wischnowsky"'s message of "Fri, 19 Feb 1999 12:12:33 NFT." <199902191112.MAA10908@beta.informatik.hu-berlin.de>

Sven Wischnowsky wrote:
> - Due to getting the patterns automatically from the files they are
>   not sorted. This may be an argument in favor of the simplified
>   processing I used in the `Comp' example directory.

But isn't that simply because there's now no way to handle patterns?  That
doesn't seem to me an advantage.

I don't like Functions/Comp as it stands, because there's no way of
automatically defining the relationship between a $COMMAND and a
__function, so I haven't tested it out properly.  I very much prefer a
modular system, which can handle one file per command (or even per suite of
commands), otherwise it makes altering the system and tracking what's going
on just too difficult.  This is for me one of the major advantages of the
new completion system: a single file can replace a ragbag of
initialisations and functions.  I'm quite happy with having some notion of
context built in alongside this.  We already have things a bit like that
with helpers like __files providing common completions for particular
contexts.

> - We probably should also completely remove the completion-array-handling.
>   This would make the code much cleaner, would allow us to get rid of
>   the callcomplete-trampoline, and would allow us to call dump anytime.

Yes, I was wondering about this.  Having a lot of autoloaded functions just
call complist isn't so much worse than than having all the baggage for
handling variables, and this time the simplification would certainly make
the interface no less powerful.  Also, we keep particular completions
within the functions namespace and avoid the variables namespace except for
special usage.  So I'm in favour.  I'll put the new version (which has now
arrived) in pws-9.  The directory will still be Functions/Completion .

-- 
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-02-20 10:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-02-19 11:12 Sven Wischnowsky
1999-02-19 14:53 ` Peter Stephenson [this message]
  -- strict thread matches above, loose matches on Subject: below --
1999-02-22 14:07 Sven Wischnowsky
1999-02-22 13:44 Sven Wischnowsky
1999-02-22  7:51 Sven Wischnowsky
1999-02-19 11:46 Sven Wischnowsky
1999-02-19  9:58 Peter Stephenson
1999-02-19 10:27 ` Peter Stephenson
1999-02-19 10:33 ` Peter Stephenson
1999-02-22 13:28   ` Peter Stephenson

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=9902191453.AA11538@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).