nesono

Thanks guys, especially deanishe for pointing the file descriptor issue out. That was what I was missing.

For the record: I also had to modify the path variable to the ack script to use ack.vim - in case anyone uses

custom packages that need to invoke binaries from within vim...

 

Type `ps aux|grep mvim| grep -v grep`.

 

That should show you whether or not the Alfred process is still running; if it is, then Alfred probably won't launch another one because it's still waiting for the first one to finish. (This depends on how you set it up).

 

If this actually is the problem, then you can fix it by forking and disowning the process so that Alfred feels like his job is done and will move on to the next.

Thanks for the answers! I am using a keyword with an argument to fire the script off.

ps did list only the macvim jobs (mvim is actually a shell script that fires off an Application.

Will mvim be actually part of the (workflow) executable when run? I though it all runs within

the context of Alfred.

Anyhow, I tried to disown the process nevertheless but it did not help.

I just added some logging (date print outs to the script) and it shows that the

workflow is not being called until the current mvim window has been closed.

I changed MVIM to be "open -a MacVim" (even though that does not what I want)

and the workflow ran every time I fired.

So the problem must be somewhere in the guts of the mvim script that comes

with home brew. Needs some further investigation though. Will keep you posted

and would be happy to hear new comments/ideas in the meantime

Hi All,

I want to fire off MacVim with a keyword action and a shortcut for where to open MacVim, e.g.:

mvim d -> open MacVim in the folder ~/Downloads
mvim h -> open MacVim in the folder ~/
...

I wrote a case statement in bash like this:

MVIM=/usr/local/bin/mvim

case "{query}" in
  "h")
    cd ~/ && $MVIM
  ;;
  "d")
    cd ~/Downloads && $MVIM
  ;;
  *)
    echo "unknown directory specified"
  ;;
esac

And when I run (e.g., mvim d) it once works flawlessly. However, if I want to open a second window of MacVim by running e.g. 'mvim h' nothing happens until I close the first window. It feels like the calls are queued (or mvim is not detached from the shell and keeps the workflow open and blocks it).

Is this by design or could somebody give me a hint how to work around this?

Thanks in advance,

jochen

I created this workflow some time ago and use it quite frequently when switching back and forth from using trackpad and mouse input devices. I needed this workflow since I prefer natural scrolling with the track pad and old-school scrolling when using a mouse. I was not completely happy with the 'reverse scrolling' application as it added lag and was misbehaving when having a finger on the trackpad and scrolling with the mouse.
 
The workflow makes a relatively simple AppleScript call, which should remain stable as long as the trackpad prefpane GUI remains the same.

The workflow can be found in my github repository

If you want to create it yourself, create the following nodes according to your needs:

* Hotkey - I use Ctrl-Alt-Cmd-M

* Run NSAppleScript with the content below

* Post Notification if desired

on alfred_script(q)
  tell application "System Preferences"
set current pane to pane "com.apple.preference.trackpad"
end tell


tell application "System Events"
tell application process "System Preferences"
tell tab group 1 of window "Trackpad"
click radio button 2
click checkbox 1
end tell
end tell
end tell


tell application "System Preferences"
quit
end tell
end alfred_script