Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: completion in vared
- X-seq: zsh-workers 6159
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx
- Subject: Re: completion in vared
- Date: Thu, 29 Apr 1999 09:42:56 -0700
- In-reply-to: <199904290905.LAA19906@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
- References: <199904290905.LAA19906@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
On Apr 29, 11:05am, Sven Wischnowsky wrote:
} Subject: Re: completion in vared
}
} Sidenote: The code uses a mask to say which of the special completion
} parameters should be set or unset. With compstate[vared] we
} have reached 32. If anyone comes up with an idea for another
} key, I'll have to re-write a bit more of the code (seven
} bits can be freed, after that I would have to change even
} more).
If there are more than 32 special completion parameters, I think we've
failed in our goal to make the whole system easier to understand.
By the way, if we're reasonably confident that we've now identified all
the compctl-isms that it's useful to put into compadd/gen/etc., I think
we should seriously look at rewriting the option parsing for those new
commands to abandon the compctl syntax. Part of the reason for creating
the new system was because compctl was so hard to comprehend; we've made
the new system a lot more powerful, but made little progress on making
it easy to understand. So far we've mostly taken the confusing compctl
stuff, stick new command names in front of it, and wrap it in confusing
shell-script stuff.
Yes, I'm exaggerating a little, but you can't really say the flow of
control is obvious through the current set of completion functions.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
Messages sorted by:
Reverse Date,
Date,
Thread,
Author