Re: compadd -r

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

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 <str>'.
> } > 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@xxxxxxxxxxxxxxxxxxxxxxx