After running a command, some processing occurs on a background thread. When that's done, it notifies the main thread, which adds the item to the history. The earliest that the main thread can respond to the notification is in its main "event loop", which is a call to select(). So the history item only gets added after the next prompt is displayed.
Incidentally, I believe this is why if you run 'exit', it doesn't show up in history. On Dec 18, 2012, at 7:05 AM, Cheer Xiao <xiaqq...@gmail.com> wrote: > 2012/12/16 Cheer Xiao <xiaqq...@gmail.com>: >> Hi Ray, >> >> I left a message on GTalk, but in case someone else is interested too: >> >> 2012/12/14 Ray <i...@maskray.me>: >>> Hi all, >>> >>> I'm a new fish user escaping from the zsh camp :) >>> >>> autojump is a productivity boost tool to chdir quickly >>> (https://github.com/joelthelion/autojump/wiki). >>> >>> j proj -> ~/to/long/dont/read/projects >>> >>> fasd absorbs autojump's idea and makes it convenient to reference file in a >>> similar manner on the command line. >>> >>> v often-accessed-file -> vim >>> ~/a/very/long/path/containing/an/often-accessed-file >>> o may-be-a-web-page -> xdg-open >>> ~/i/am/a/haskell/enthusiast/may-be-a-web-page >>> >>> I know that the chdir feature (initiated by autojump) can be worked around >>> by fish_prompt, however, >>> it seems difficult to emulate the file-reference feature (v >>> often-accessed-file) without some hooks. >>> >> >> Instead of hacking fish_prompt, you can bind a function to the event >> with the same name: >> >> function save_pwd --on-event fish_prompt >> ... >> end >> >>> As far as I know, fish does not have such preexec hook (zsh's preexec). >>> Have you considered adding such hooks or implement this functionality in >>> the core (it's very slow for fasd to use many awk scripts and others). >> >> Since you are already abusing the fish_prompt event, you can emulate >> preexec by peeking at $history[1] in a function bound to the >> fish_prompt event, which always contain the last executed command. The >> trigger for fish_prompt is roughly equivalent to that of precmd in >> zsh, and I think the difference between precmd and preexec doesn't >> make much difference here. >> >> Judging by zshmisc(1): >> >> preexec >> Executed just after a command has been read and is about >> to be exe‐ >> cuted. If the history mechanism is active (and the >> line was not >> discarded from the history buffer), the string that the >> user typed >> is passed as the first argument, otherwise it is an >> empty string. >> The actual command that will be executed >> (including expanded >> aliases) is passed in two different forms: the second >> argument is a >> single-line, size-limited version of the command (with >> things like >> function bodies elided); the third argument contains the >> full text >> that is being executed. >> >> $history[1] seems pretty close. >> > > After a little experimentation, it seems $history[1] doesn't do the trick: > > xiaq ~> function --on-event fish_prompt foo > echo $history[1] > end > vim .xinitrc > xiaq ~> echo 1 > 1 > function -e fish_prompt foo > echo $history[1] > end > xiaq ~> echo 2 > 2 > echo 1 > xiaq ~> echo 3 > 3 > echo 2 > xiaq ~> sleep 1 > echo 3 > > Instead of the last executed command, $history[1] contains *last but > one* executed command. I doubted that this is related to the fact that > history saving is done in another thread in parallel with command > evaluation, so that there is chance that when fish_prompt gets called, > history saving is not yet finished. However, that doesn't seem to be > the case, as after a command that takes rather long (the last `sleep > 1`), $history[1] is still the last but one executed command. > >> However, I think preexec can be made much better if individual tokens >> (instead of whole command lines) are passed to the hook function, so >> that after defining foo like (supposing a "preexec" event is >> implemented in fish): >> >> function foo --on-event preexec >> ... >> end >> >> Typing a command "echo a b c" results in foo gets called with 3 >> arguments, 'echo', 'a' and 'b' instead of 'echo a b' bundled together. >> Whether tokens are expanded before being passed still needs to be >> considered - typing "echo a{b,c}" might call foo with 'echo' and >> 'a{b,c}', or 'echo', 'ab' and 'ac'. I'm not sure which is more useful. >> >> One last little point - I think preexec is a pretty bad name. There is >> an exec builtin, and preexec might lead one to believe that it is >> called before exec is executed. (precmd is even worse; fish_prompt is >> way better that precmd.) I wish fish can use better names for similar >> functionalities. > > > -- > Regards, > Cheer Xiao > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Fish-users mailing list > Fish-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/fish-users > ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Fish-users mailing list Fish-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fish-users
