I didn’t see this answered though I suspect it has been.
Is there a way to tag files as they are captured with the F1 key?
For example, Yojimbo allows one to assign tags (via a dialogue box) when capturing a web archive from a browser, my most common import action, instead of locating the file in the database afterwards and adding tags.
In the meantime, you can customize the capture script(s) for application(s) you need this for:
set the_tag_string to text returned of (display dialog "List tags" buttons {"OK"} default button "OK" default answer "")
...
return {{|url|:theURL, |tagsString|:the_tag_string}}
I am very interested in this feature too. Not to push, Michael, but would you be willing to say if this is on a front burner or a back burner? Thanks. I’ve been testing Yojimbo, DevonThink, etc. and I prefer EF except for the feature that Yojimbo has on being able to tag at the same time as you quickly capture (a web page, in my case).
I had not been planning to do that, since my thought was that people would use the “import” script command for fully-automated imports and press the capture key for interactive imports. You seem to be imagining a hybrid situation—could you describe a bit more about what you’re trying to do?
First, there do remain a few applications that are not currently supported by the capture key. (But wait, if you write a custom capture script, will it run/work if you invoke Capture With Options? If so, are the |tags|, |sourceURL|, etc. applied before or after the Capture With Options dialog? I haven’t tried yet.)
Second, If you capture text or an image from within a document via the EagleFiler:Import service menu item, then there is (currently) no way to tag, annotate, etc. during the import (the same situation that existed with F1 capture before this new feature).
And finally, I have a script that imports emails as text (yes, I know, but I have my reasons). The script asks for the library and tags during import, but it would be nice to also get notes, label, a title, etc. without having to throw up a dozen dialogs.
Well, if you can script it to use the “import” verb, you should be able to script it to write a capture script.
Yes.
Whatever you enter in the dialog overrides the information from the capture script. But, for example, you can leave the Title field in the dialog blank, and then it will fall back on the |title| in the capture script (if present) or else inspect the file itself.
That’s a true statement, but I don’t see how the system service relates to AppleScript and your feature request.
OK, so this is a situation where the application has a capture script, but you prefer not to use it? One option would be to override the built-in capture script by writing your own and putting it in ~/Library/Application Support/EagleFiler/Capture Scripts. If you need more control than that, then I agree that some kind of “ask for options” argument for the “import” verb would be needed.
Ok, so apparently I confused myself. I really wanted the option to chose a library at the time of import, so I wrote several scripts that did just that. I used them like capture scripts, but they were actually regular scripts (using the “import” verb). Furthermore, I assigned them a the keystroke option-F1 in Quicksilver. So when I tried to use the new Capture With Options feature, it appeared to not work with custom capture scripts because I did not have any actual capture scripts at all, but my regular scripts ran instead. Sorry for the confusion.
The only relation is that applescript hooks would allow one to write a script that had the same functionality of the service menu item with the addition of the capture options dialog.
Yes. I’ll just need to adjust my import-email-as-text script to actually be a custom capture script, which I couldn’t do before because the library-selection code did not work within a capture script. The new feature makes that part unnecessary.
It would be simpler, however, if capture scripts accepted |text| and/or |plain text| keys in addition to |path| and |URL| keys – just like one can do “import text” and “import plain text” in addition to “import files” and “import URLs”. It would just save having to write all those temporary files.
I don’t think so, because as far as I know the service menu functionality (e.g. getting the selected rich text of the frontmost window) is not available to AppleScript.
AppleScript’s rich text support isn’t great, so I don’t know if |text| could work. There is an undocumented (still somewhat experimental) |data| key that takes a string and generates a plain text (UTF-8) file for you.