wolph Posted December 24, 2014 Share Posted December 24, 2014 True, but it required a bit of searching to find the config now the problem was that somehow the default json editor of OSX used curved quotes (which was not visible in my font). Guess that teaches me to edit files with anything but Vim... Guess I never do a regular open on json files... Link to comment
deanishe Posted December 24, 2014 Author Share Posted December 24, 2014 Oh, right. TextEdit bit you, too, did it? The dumb "smart" quote thing is super annoying. TBH, if Apple is going to set TextEdit as the default editor for JSON files, it should make sure it doesn't break them by default. I'm looking into fixing things so the error in settings is caught like other errors. Might require quite a bit of work, though. Link to comment
wolph Posted December 24, 2014 Share Posted December 24, 2014 Jup, TextEdit is really crappy... I've just replaced it with a symlink to Vim now As for the error, just having a default file and a try/catch around the loading of the personal settings file would help a bit already, but only for the reposettings command I guess. Link to comment
deanishe Posted December 25, 2014 Author Share Posted December 25, 2014 (edited) It's not that simple, I'm afraid. The settings file is a part of the underlying Alfred-Workflow library (which is what also catches and displays the errors). I need to go through that carefully to ensure that the settings file isn't loaded by the library before the Workflow.run() method is called. My suspicion is that the update functionality is doing it, but if that isn't the case, it may be tricky to also catch that error. Edited December 25, 2014 by deanishe Link to comment
wolph Posted December 25, 2014 Share Posted December 25, 2014 (edited) Looking at the traceback and the source, one (hacky) option could be to catch the creation of the workflow and trying it without the update: i.e.: try: wf = Workflow(default_settings=DEFAULT_SETTINGS, update_settings=GITHUB_UPDATE_CONF, help_url=HELP_URL) except: # Are there specific exceptions to catch here? wf = Workflow(default_settings=DEFAULT_SETTINGS, help_url=HELP_URL) Ok... somehow this forum screws up the indenting, but you get the point Edited December 25, 2014 by wolph Link to comment
deanishe Posted December 25, 2014 Author Share Posted December 25, 2014 I know what the problem is, thanks. I'm working on a solution that isn't hacky. Link to comment
wolph Posted December 25, 2014 Share Posted December 25, 2014 No problem, I didn't see any other options without modifying Alfred-Workflow though. I'll take a look at Alfred-Workflow soon, see if I can think of a clean solution. Perhaps I'll try it for one of my projects too. Link to comment
deanishe Posted December 25, 2014 Author Share Posted December 25, 2014 The non-hacky solution is to modify Alfred-Workflow. A slightly less hacky workflow-specific solution would have been to set Workflow._update_settings and call Workflow.check_update() from within main(), where it would have been subject to Workflow's error catching and logging. Link to comment
deanishe Posted August 7, 2015 Author Share Posted August 7, 2015 (edited) Two cool new features added today, thanks to other GitHub users. git worktrees are now supported. If you configure a browser as one of your apps, the remote repo URL will be passed to it, instead of the local directory path. Grab v1.7 from GitHub or Packal (or just enter repos workflow:update in Alfred). Edited August 7, 2015 by deanishe Link to comment
Doom Posted August 11, 2015 Share Posted August 11, 2015 (edited) I really love this workflow!!!Added Google Chrome (opens bitbucket or github <3) and Tower (opens the repo in Tower <3<3)PERFECT! I just don't understand why it shows me the Git Root Folder (there is no .git directory or so). see: second entry http://i.dv.tl/Screenshot_2015-08-11_at_04.41.48.png EDIT: nevermind, there WAS a .git dir, I have no idea why removed and it works fine! thx Edited August 11, 2015 by FirePanther Link to comment
Maddog Posted August 27, 2015 Share Posted August 27, 2015 Weird story - I installed and depth wasn't deep enough, so I changed it and the update command didn't work, so I removed all the cache files (cpickle?) and now I'm getting this error and nothing works: workflow.py:1978 ERROR Command '[u'find', u'-L', u'/Users/user/Code/', u'-name', u'.git', u'-maxdepth', '5']' returned non-zero exit status 1 When I run the same command from the terminal it works. Any suggestions? I tried reinstalling the workflow. Link to comment
deanishe Posted August 27, 2015 Author Share Posted August 27, 2015 That's a tricky one. Does your username include any non-ASCII characters? Are you definitely using the same find command (i.e. have you installed coreutils or the like from Homebrew)? Perhaps try running the command from your terminal with an empty environment (env -i /usr/bin/find -L …) and see if that throws an error. Link to comment
Maddog Posted August 27, 2015 Share Posted August 27, 2015 My username only contains letters. I tried running the command from the terminal, with "env -i", like you said and it worked. I don't think I've replaced any core command line utils. I want to stress the point that it worked once and gave me a list of repos with depth:2. Link to comment
deanishe Posted August 27, 2015 Author Share Posted August 27, 2015 I honestly don't know what the problem might be. I can't replicate it. Could you create a new Run Script action in the workflow with language=bash and put the offending find command in it? Trigger that action and see what happens. I suspect it may be a bad interaction between find and Alfred's empty environment. Link to comment
Maddog Posted August 27, 2015 Share Posted August 27, 2015 Ha! Insight! I have one directory that is non-accessible to find due to permissions. Could that be it? How can the script ignore that error? Link to comment
deanishe Posted August 27, 2015 Author Share Posted August 27, 2015 Fixing the permissions would seem the best solution. If that's not possible, enter reposhelp and see the "excludes" part of the configuration file. Link to comment
Maddog Posted August 27, 2015 Share Posted August 27, 2015 isn't excludes used after the find command? I tried that. I have unit tests that refer to that directory, kinda hard to change the permissions becase the tests would start failing Link to comment
deanishe Posted August 27, 2015 Author Share Posted August 27, 2015 Oh, yeah. Find doesn't do excludes. I don't have any other ideas at the moment. I suppose the workflow could check to see if find is producing valid output and use it regardless. My gut feeling is still that having user-inaccessible folders/files under ~/ is the root problem. Link to comment
Maddog Posted August 27, 2015 Share Posted August 27, 2015 (edited) It's weird the script can't ignore the stderr. I mean it's not like find itself crashes, just raises one stderr. I know it's my fault, don't know why I keep bugging you Thanks for your help, I'll fix it on my end, maybe my unit test could create that directory (probably makes more sense anyway). EDIT: Now that it's working, I'm loving it so much! Edited August 27, 2015 by Maddog Link to comment
deanishe Posted August 28, 2015 Author Share Posted August 28, 2015 It's weird the script can't ignore the stderr. I mean it's not like find itself crashes, just raises one stderr. The script does ignore STDERR. The issue is that find is exiting with a non-zero status (i.e. an error). maybe my unit test could create that directory (probably makes more sense anyway). I think that's probably the most correct solution. Having directories in ~/ that you can't open/read is a bit of an odd situation, and would presumably cause issues for backup software and Spotlight. EDIT: Now that it's working, I'm loving it so much! Thanks! Of all the workflows I've written, this is the one I use the most personally. Link to comment
Maddog Posted September 17, 2015 Share Posted September 17, 2015 so it seems like a concept of "default editor" exists in git - https://help.github.com/articles/associating-text-editors-with-git/ Would be really nice instead of remembering the correct button, if it could just open the correct editor for the project. I have projects in multiple languages and would be nice to be able to just hit enter instead of remembering the correct editor button. Just a thought. Link to comment
deanishe Posted September 17, 2015 Author Share Posted September 17, 2015 Are you suggesting using the configured git editor by default? Link to comment
Maddog Posted September 17, 2015 Share Posted September 17, 2015 I'm just suggesting making it possible via the config, like instead of assigning a specific program, the user would use a special keyword in the config like "$defaultEditor". Link to comment
deanishe Posted September 17, 2015 Author Share Posted September 17, 2015 (edited) But what does "$defaultEditor" refer to? The git editor is what is used by git when it wants you to enter/edit a commit message. Changing that to something like Eclipse is probably not what you want, and you'll note that in the git docs that you linked to, when you specify a GUI editor, you also have to specify whichever flag they use to tell them to not exit till the file is closed (otherwise git will continue immediately). In terms of repo-specific configuration, my preferred solution would be an alfred-repos.json file that overrides the "app_1", "app_2" etc. keys in the global configuration file. Then you could execute echo '{"app_1": "Eclipse"}' > alfred-repos.json in your project directory to override the default action. This has the advantage of enabling you to override all the app_* settings. Edited September 17, 2015 by deanishe Link to comment
Maddog Posted September 17, 2015 Share Posted September 17, 2015 (edited) Oops, my fault, I have read on other pages that the git editor is for entering interactive commands, but seeing IDEs on that github page made me think it's for general use as well. Then definitely, your method is way better. Edited September 17, 2015 by Maddog Link to comment
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now