From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7263 invoked from network); 9 Feb 1999 08:21:19 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 9 Feb 1999 08:21:19 -0000 Received: (qmail 2923 invoked by alias); 9 Feb 1999 08:20:50 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5328 Received: (qmail 2916 invoked from network); 9 Feb 1999 08:20:49 -0000 Date: Tue, 9 Feb 1999 09:20:05 +0100 (MET) Message-Id: <199902090820.JAA28460@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Mon, 8 Feb 1999 09:37:40 -0800 Subject: Re: compadd -r Bart Schaefer wrote: > On Feb 8, 1:17pm, Sven Wischnowsky wrote: > } Subject: Re: compadd -r > } > } Bart Schaefer wrote: > } > } > How about this: For the simple case (remove the whole suffix, which I > } > suspect is the most common by far) stick with something like `-r '. > } > For complex cases, let the user give the name of a user-defined function > } > that is called as a callback as if it were a ZLE widget, that is, with > } > LBUFFER and RBUFFER etc. writable, and with the keystrokes that caused > } > it to be called also available somewhere. > } > } The easiest way to do this is to add a function-pointer-variable in > } the zle module that will be called whenever zle thinks that a suffix > } should be removed. The completion module sets this variable whenever > } it needs it to the address of a function that calls the given shell > } function. > > Isn't this more complicated than necessary? Why couldn't it be the same > function pointer every time? All it has to do is the equivalent of > > zle user-defined-widget Of course we could make the completion code set the pointer to the function that removes the suffix when it's loaded and reset it to NULL when it is unloaded. But zle would have to call this function every time a suffix might have to be removed, so I thought the code probably should save some time by calling a function only if there is a shell function to be called to remove the suffix. > } This is easy to implement, but somehow I think that we probably should > } take this as an example for a more gerneral problem (calling functions > } in sub-modules from modules they depend upon), and solve that one. > > Eh? There isn't any such dependency here, is there? The compctl module > already depends on zle, and it's calling a function in zle. I thought about placing the code to call the shell function in the completion code (after all that's where the need for it is detected). With this it would be zle calling a function in the completion code. What I didn't think about (and what you seem to mean) is to put the code in zle and let the completion code just signal zle to call the shell function. Indeed, yes, that would be even easier. > } What I'm thinking about is some kind of hook-mechanism. Giving modules > } the possibility to register functions that should be called whenever > } some event happens. > > This is, in effect, what the "wrappers" already are. For one such type of events, yes. > } By making the description of the hooks contain a `char *name' this > } could also easily exposed to user level to let users register shell > } function to be executed when a hook is run. The builtin to control > } this could be added in a separate module, of course. > > Have you finished reimplementing emacs yet? No, still working on this... But yes, I like the comparison (and we had this discussion about hooks some years ago already, where it was me mentioning emacs). Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de