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.
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.
Also, I think a function copy feature is better than a rename feature. If
you have copy, you can do rename by removing the old one. If you only have
rename, you can't get copy behaviour without ugly eval hacks. And it might
be helpful to start with the code of the old function when you funced the
new function. I think it's a bit overkill to have both a copy and a rename,
but I don't care a lot.
Though I don't know how hard it is to program function copying.
Btw, I've added you to the fish-developers group, so you can put your branch
directly in the 'real' repo.
Jan
On Tue, Sep 7, 2010 at 20:39, Christopher Nilsson <
christop...@otherchirps.net> wrote:
> Ok, I've given this a go.
>
> There's a patch over in my gitorious clone, on the "function-rename"
> branch:
> http://gitorious.org/~otherchirps/fish-shell/otherchirps-fish-shell<http://gitorious.org/%7Eotherchirps/fish-shell/otherchirps-fish-shell>
>
> It's at a "works for me stage". :)
>
> Example output:
>
> > function foo
> echo Hello
> end
>
> > foo
> Hello
>
> > functions --rename foo bar
> > foo
> fish: Unknown command 'foo'
>
> > bar
> Hello
>
>
> > functions --rename fish_prompt old_prompt
> > function fish_prompt
> printf "{Boo!}%s" (old_prompt)
> end
> {Boo!}>
>
> Note in the last case, the new fish_prompt is calling its old definition,
> which was my original aim.
>
> Now, I'm still getting my head around the codebase, so let me know if I've
> broken something.
>
> I'm really not sure if my new function_copy() function is doing the right
> thing.
> Specifically with the way it's trying to wire up the new function clone
> with the old one's events.
>
> Is it registering with the same events ok? *Should* it be registering with
> the same events at all?
>
> Anyway, feedback is welcome.
>
> - Chris.
>
>
>
> On 29 August 2010 22:04, Jan Kanis <j...@jankanis.nl> wrote:
>
>>
>>
>> On Sat, Aug 28, 2010 at 20:27, Christopher Nilsson <
>> christop...@otherchirps.net> wrote:
>>
>>> Hi Jan & Info,
>>>
>>> Thanks -- that's just what I was after! I do prefer only messing with
>>> the in-memory function, as this prompt prefixing is only meant to be
>>> temporary. Jan's method, with the deletion of the tmpfile before adding a
>>> new fish_prompt, sounds like the closest match to that.
>>>
>>>
>>> A builtin way of doing this would be cool. eg.
>>>
>>> functions --rename fish_prompt old_prompt
>>>
>>>
>> I totally agree this is needed.
>>
>> Jan
>>
>>
>>
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Fish-users mailing list
Fish-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fish-users
