On Wed, 14 Dec 2005, Harshad wrote:

> Axel Liljencrantz wrote:
> > Silly me. An event handler is a command substitution, so that will always
> > evaulate to true.
> >
> > Ok, new approach. Lets' define a cd function. The trouble here is that a
> > cd wrapper function is already defined, doing things with the directory
> > history. So we redefine it as __cd_wrapper. Something like this:
> >
> > eval (functions cd|sed -e 's/function cd/function __cd_wrapper/')\n
> > function cd
> >     __cd_wrapper $argv
> >     if status --is-command-substitution
> >         return
> >     end
> >     blah blah blah
> > end
>
> This works.
>
> > A bit of a hack, but it could be worse.
>
> There should be a simpler way to insert hooks, without knowing the global
> state. The effect of a change, especially by the end-user, should be
> localised, not heavily dependent on knowledge of the entire system, and in
> turn, the user level change should not alter the global defns.

The long term solution is to extend the fish event delivery
framework. A future version of fish might have something like this in
the cd shellscript:

event --send --name change_directory

which can be caught by

function cd_list_handler --on-event change_directory
    ...
end

Or, even better, it should be possible to attach events to a command,
so that you can specify that a handeler should be run after a
specific command has been run. Somthing like:

function cd_list_handelr --on_after command cd
    ...
end

I'm trying to introduce the event syntax one step at a time, but this
kind of generic event passing has always been part of the plan for
the event framework.

>
> >
> >>>> Zsh has a function called chpwd() that gets called whenever the working
> >>>> directory gets changed (from the user's point of view). Can something
> >>>> similar be defined for fish?
> >>>>
>
> The Zsh solution is simpler and robust, I think.
>
> I hope comparisons with other shells are welcomed here. Fish has a nice set
> of features, but it will have to put in a little extra thought to become
> robust and intuitive.
>

They are welcome. I wrote fish because I was frustrated with bash and
zsh and wanted something better. But there are still things that
those shells do better than fish, and no one benefits from pretending
otherwise. I want to rework those things until fish is perfect in
every way. An interative process with an infinite number of steps.


-- 
Axel


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Fish-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fish-users

Reply via email to