I finally had a chance to get back to this. On 8 September 2010 09:50, Jan Kanis <j...@jankanis.nl> wrote: > >> About the events: I think copied functions should not be connected to >> their parents events, otherwise the original use case of 'extending a >> function' doesn't work for event handlers. If function oldfoo is invoked on >> fooevent, and I want to have e.g. >> >> function newfoo >> oldfoo nondefaultparam >> end >> >> do the job instead, I want newfoo to be connected when fooevent fires, and >> not oldfoo, otherwise oldfoo is called twice. >> >
I've replaced "--rename" with a "--copy" option instead. It should be doing this ok now, and not duplicating the event subscriptions of the original. It's up in the main gitorious repo, in the "otherchirps-dev" branch ( http://gitorious.org/fish-shell/fish-shell/commits/otherchirps-dev). On a separate thing: > >> But that again suggests that it might be handy to be able to edit the >> events a function is connected to after it has already been created. (just >> thinking.) Thinking some more, I wouldn't mind being able to easily see and >> set what functions are registered for an event handler. >> > > No editing so far, but I've had a play with showing what handlers are registered. Over in my clone, there's a "listeners" builtin which will spit out all the function names listening for a given event/signal/variable change, etc. ( http://gitorious.org/~otherchirps/fish-shell/otherchirps-fish-shell/commits/listeners ) eg. > function test --on-event foo_event echo ping! end > function another_one --on-event foo_event echo ping2 end > listeners --event=foo_event another_one test Was this the sort of thing you were thinking of, as far as seeing what functions are registered? I was in two minds about busting out another builtin for this, since it feels like this should probably be the job of "functions". But since "-e" was already taken anyway, and there were "-s, -p, -j, -v" to add.... was starting to clutter it a bit. Another way might be to overload some existing options, like "query". eg. > functions -q --on-event=foo_event another_one test Don't know. Would also need to think about syntax for setting... If anyone has ideas on doing this better, let me know. Cheers, Chris.
------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________ Fish-users mailing list Fish-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fish-users
