* Re: Rough Draft of Article on Writing Completion Functions [not found] <E16tQka-0005p0-00@bimbo.logica.co.uk> @ 2002-04-05 19:28 ` John Beppu 0 siblings, 0 replies; 4+ messages in thread From: John Beppu @ 2002-04-05 19:28 UTC (permalink / raw) To: Oliver Kiddle; +Cc: zsh-workers [ date ] 2002/04/05 | Friday | 11:15 AM [ author ] Oliver Kiddle <okiddle@yahoo.co.uk> > > If anything strikes you as being wrong, let me know. > I couldn't see anything wrong besides what Sven has already picked up > on. If you didn't get Sven's reply, it is because he seems to have sent > it to zsh-workers only so check the mailing list archives. Actually, I meant to send it to zsh-workers only, but I accidentally sent it to zsh-users. In mutt, I hit reply when the cursor was on that message by that John guy who wanted a zsh equivalent of the bash completion project. Little did he know... haha. But anyway, I got rid of the In-Reply-To: header, but failed to notice the To: header said zsh-users in it. However, it seems as if I've helped at least one person on zsh-users who had some nice things to say in a private email, so it was a fortunate accident. > Is there going to be any surrounding context or whatever from which > it will be at least clear what zsh is? I'm kinda hoping people can give it a glance, and figure out what zsh is by using their intuition. > > SUBHEAD: The Pros and Cons of the Various Sources of Information > > You could also mention the mailing lists as a source of information in > this section. Though they probably aren't so much a starting point as a > place to go later. I had the same feeling, but I didn't know where to put it, and by the time I got to the end of writing, I forgot about it. I think I'll mention it somewhere in the concluding parts. > > You don't need to know a lot more than this to effectively write > > completion functions, so without further adieu, let's look at an > > I thought that phrase was normally `further ado', or am I wrong. I looked into that, and it turns out you're right. There is a French adieu that means goodbye, and it's totally unrelated to the English ado which has the meaning that I actually wanted. Good catch. > > [ BEGIN SIDEBAR 4 - Refinements ] > > > > [ JSB: this entire sidebar is optional ] > > > > Oliver Kiddle from the zsh-workers mailing list suggested the following > > improvements to I<_figlet>. > > If this sidebar doesn't make it in you could mention briefly that the > _figlet that will be distributed with the next version of zsh includes > a few improvements. OK. I think how I'll do it is by putting a comment in the code listing with a message that states that there's a new and improved one coming up. The only reason I didn't use your suggestions in the main listing was that I wanted to show people how states worked. Peace, beppu PS: I have some urgent business to take care of, and I might not have the time to address some of the comments I saw on zsh-workers until tomorrow or even Sunday. I've read them, and I have replies to them stewing in my mind, but I don't have time to write them down. Please be patient with me. ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <20020404234932.GA27875@Ax9.org>]
* Re: Rough Draft of Article on Writing Completion Functions [not found] <20020404234932.GA27875@Ax9.org> @ 2002-04-05 7:05 ` Sven Wischnowsky 2002-04-11 19:48 ` John Beppu [not found] ` <7906.1018000673@csr.com> 1 sibling, 1 reply; 4+ messages in thread From: Sven Wischnowsky @ 2002-04-05 7:05 UTC (permalink / raw) To: zsh-workers John Beppu wrote: > ... > > The C<_arguments> function is a wrapper around the C<compadd> > builtin like so many other auxiliary functions that come with Zsh. > Ultimately, it is C<compadd> that takes a list of information and > feeds it to the core of the completion system so that Zsh can > display the results of a completion request on the terminal. The > other builtin to be aware of is C<compdef> which is used to bind > completion functions to commands. See the sidebar on C<compadd> and > C<compdef> to see them being used in combination. compdef is actually a function defined in compinit. And nowadays there's not even specialised C-code behind it, just assocs and stuff. > ... > > However, on line 26, we encounter a new kind of option that takes an > argument. The C<-w> option tells I<figlet> how many characters wide the > output should be, and it takes an integer as an argument. There are > only 2 differences here. The first difference is that the option part > has a + after it, so it says C<-w+>, now. The + means that this option > takes another argument. The second difference is that there is an > additional string after the description that is used as a hint when the > user presses tab. However, it is only visible when you've set your > verbosity up as described in I<Preparations>. A `+' after the option name means that the argument may come directly after the option in the same word or in the next word. That there is an argument to come is said by the `:descr:action' after the option description. And we normally suggest to not leave out the colon before the action even if there is no action. Just to help _arguments to parse the stuff (well, we had some problems which should be fixed, but...). Personally I also find it a little less confusing with the trailing colon before the empty action. > Line 29 adds another variation. Here we have an option, that takes an > argument, that is easily predictable. There are only 6 possible > arguments that C<-I> can take, so after the hint, we list those 6 > arguments in parentheses. > > Line 30 adds yet another variation. The C<-d> option wants > a directory as an argument, so we use the C<_path_files> function to > build the list for us. Like C<_arguments>, C<_path_files> is also a > front-end to C<compadd>. This should use _files. Everyone should use _files. Almost noone should use _path_files. _files allows users to override glob patterns and stuff. > ... > > However, when we use the state mechanism, we're going to fall through > and hit line 36 to adjust the C<$fontdir> directory if necessary, and > then on line 38, we're going to hit the case statement. Based on the > value of the C<$state> variable, we're either going to build a > completion list for fonts or control files. In both cases, we're going > to use the C<_files> function which appropriately enough builds > completion lists for files. Using the C<-W> option, we root the search > for completions in whatever C<$fontdir> is, and using the C<-g> option, > we specify a glob pattern that limits which files are returned in the > completion list. In fact, the glob pattern is the only difference > between font completion and control file completion, and even the glob > pattern is only different by one letter. What a waste of code. Oh > well. At least it works, and it's not ugly. An alternative to this and the stuff in sidebar 4 would be to declare a local function, call it from the _arguments-actions and there give it an argument of `flf' or `flc'. Bye Sven -- Sven Wischnowsky wischnow@berkom.de ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Rough Draft of Article on Writing Completion Functions 2002-04-05 7:05 ` Sven Wischnowsky @ 2002-04-11 19:48 ` John Beppu 0 siblings, 0 replies; 4+ messages in thread From: John Beppu @ 2002-04-11 19:48 UTC (permalink / raw) To: Sven Wischnowsky; +Cc: zsh-workers [ date ] 2002/04/05 | Friday | 09:05 AM [ author ] Sven Wischnowsky <wischnow@berkom.de> > compdef is actually a function defined in compinit. And nowadays > there's not even specialised C-code behind it, just assocs and stuff. fixed. > A `+' after the option name means that the argument may come directly > after the option in the same word or in the next word. That there is > an argument to come is said by the `:descr:action' after the option > description. fixed. > And we normally suggest to not leave out the colon before the action > even if there is no action. Just to help _arguments to parse the stuff > (well, we had some problems which should be fixed, but...). Personally > I also find it a little less confusing with the trailing colon before > the empty action. I kinda hesitated on this one, but I did it, anyway. fixed. > This should use _files. Everyone should use _files. Almost noone > should use _path_files. _files allows users to override glob patterns > and stuff. fixed. > An alternative to this and the stuff in sidebar 4 would be to declare > a local function, call it from the _arguments-actions and there give > it an argument of `flf' or `flc'. I was just being silly towards the end. :-) ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <7906.1018000673@csr.com>]
* Re: Rough Draft of Article on Writing Completion Functions [not found] ` <7906.1018000673@csr.com> @ 2002-04-11 19:46 ` John Beppu 0 siblings, 0 replies; 4+ messages in thread From: John Beppu @ 2002-04-11 19:46 UTC (permalink / raw) To: Zsh Workers [ date ] 2002/04/05 | Friday | 10:57 AM [ author ] Peter Stephenson <pws@csr.com> > I deliberately didn't write a whole real-world completion function > because there are already so many to look at, I think you should have done it, anyway. I'll explain why in a second. > > The great tragedy of Zsh is that they actually made it very easy to > > write completion functions, but you'd never know it by just > > reading the documentation. > > Hmm... how much simpler than > > _foo() { compadd Yan Tan Tethera; } > compdef _foo foo > > do I need to get? This is the sort of hint I need from the puzzled. Beginners don't need "simple". They need "practical". Would you tell some chump off the street: This is how to jab; This is a hook; This is an uppercut; Now go fight Mike Tyson. Clearly, this guy is going to be unprepared for the task at hand. That's why a long practical example that explains the task of writing a completion function from start to finish would have been helpful. > I suggest you mention that you need zsh 4.0.x as a matter of priority, > regardless of space limitations, or some people are going to get > confused OK. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2002-04-11 19:47 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <E16tQka-0005p0-00@bimbo.logica.co.uk> 2002-04-05 19:28 ` Rough Draft of Article on Writing Completion Functions John Beppu [not found] <20020404234932.GA27875@Ax9.org> 2002-04-05 7:05 ` Sven Wischnowsky 2002-04-11 19:48 ` John Beppu [not found] ` <7906.1018000673@csr.com> 2002-04-11 19:46 ` John Beppu
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).