> 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. > > I haven't had a look at the code yet, but it's great that someone is working on it.
If there were a way to edit a functions event bindings, what happens with the event bindings matters a little less. One could argue both ways on what copying should do with the events in that case. One could argue that a full copy of a function should include the event bindings as they are part of the function. But I can't really think of any use cases where the copying of event bindings would be usefull, so I currently don't think they should be copied. Can anybody think of any use cases where this would be desired? > 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<http://gitorious.org/%7Eotherchirps/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? > More or less. I hadn't really thought about the syntax to use, but this is the output I had in mind. The output should be a list of the functions/events that can be piped into another program, like > listeners --function=test | xargs listeners --add_events_to_func third_one (note: placeholder syntax) But for that it doesn't matter a lot if the items are space separated or newline separated. 'functions' gives a comma-space separated output of defined functions, which I would not recommend. > 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. > Yea, with this we're getting into the land of language design, where mistakes can't be corrected for fear of the daemon of backward compatibility... <<cue sinister music>> First, what do you want to do with the -s, -p, -j and -v options? I intuitively agree this should probably be the job of functions, but if so, deciding what options to use is not so straight forward. 'functions' is already used to edit a different 'property' of fuctions: the description. But given that my 'functions' only has six options in it's help page, which is a very small number compared to the average gnu utility, I am not in favor of overloading one of those like -q just yet. There's also some presendence for the new builtin variant, but if that one is chosen I'd say it should be called 'funcevent' or something similar. There are several builtins starting with 'func' that deal with fish functions. The only non fish func* command on my path is something called function_grep.pl which I've never heard of and is apparently part of wine. IMHO the choice between these two options depends in large part on this question: (Assuming optimistically that fish will once be as popular as bash is today,) Will there be a need in the future to add lots more operations dealing with functions and/or events, or will the basic add/remove/list operations be mostly all we need? If the former is true, it makes sense to make a separate builtin to deal with event bindings. In the latter case, it probably makes sense to keep the command namespace clean and add the functionality to 'functions'. Of course, the answer to that question is unknown and very hard to predict. well, at least that are some first thoughts. Jan
------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/fish-users
