smarg19

Updated to Version 1.1.1 with fixes for Latin lexica.

Parsers Greek and Latin parsers for Alfred Version: 2.0 Download at Packal This is a somewhat specialized workflow, but for those who read Greek and Latin, it will likely prove beneficial. This workflow uses the Perseus parsing backend to allow full parsing of both Greek and Latin terms. Simply use the keyword parse followed by the unknown Greek or Latin word. Parsers will automatically fetch all of the parsing data from Perseus, munch it up, and offer you all of the possible parsings via Alfred's elegant UI. If you would like a bit more information, Parsers adds two actions for any selected parsing. Using cmd+return, you can view a HUD of the parsing data chosen, pretty printed, and have that data copied to the clipboard. Greek: Latin: Alternatively, you can use shift+return to view a HUD of the lexicon entry for that parsing term, and this lexicon data will also be copied to the clipboard (NOTE: Parsers will attempt to display the lexicon entry from the most concise lexicon available for the chosen term). Greek: Latin: Let me know if you have any further feature suggestions. And enjoy your Greek and Latin, stephen

If you select "Automatically check for pre-releases" in the Alfred Update pane, you will be able to update to version 2.3 (264), which is the most up-to-date-version. Tho, it is, as the selection would suggest, a pre-release beta.

Check out my initial script in my fork of the project: https://github.com/smargh/alfred-bundler/tree/master Right now, I only have the __load() function made. As of right now, you can only pass the package name and (optionally) a version number. The bundler first checks to see if the module is in the bundler directory tree ($USER/Library/Application Support/Alfred 2/Workflow Data/alfred.bundler-aries/assets/python/). If you pass a version number, it looks for that specific version, else it looks for the most up-to-date version. If it isn't there, or that particular version isn't there, the bundler will then use pip to install the package into the bundler directory. If you didn't pass a version number, the bundler uses a tmp directory, gets the version number, then renames the sub_directory (note: I had to use sudo mv since you need root access to fiddle with Python packages (at least on my machine)). If you pass a version number, however, the bundler will create the requisite sub-directories, and install the package there. In the main() function, you can see an example of this would work for a package. Thoughts?

Ok. Here we are. pip actually has an "ignore" flag (-I), which will install a package/module ignoring if it would version conflict with a pre-installed one. But this would probably be unnecessary, since I am thinking that the simplest course of action would be to install packages into the python directory, and then afterword move them into the proper sub-directory based on the package's version number. So, there would never be a bare package in the install directory to conflict with. I'm toying with something now...

So, the basic problem (so far as I can tell) with a Python version of this logic is that you cannot import a module from another script. So, I can't have script A import a module that script B will use. You will always have to explicitly import the module within script B. This means you couldn't load the module in the bundler script. The best you could do is check if it exists where it should be, and if not, install it. Also, the funky-ness of pip installed modules isn't really a problem, because the Python import function handles all of the parsing for you. So, any module or package installed via pip by definition is structured such that you can use the import function to get it if its path is in sys.path. Given these restrictions, I think my initial thinking still makes sense.

Ok, can you help me understand things a bit more clearly. Since I barely know bash and don't know PHP, it's hard for me to follow the code. I understand the idea of having all workflow dependencies in one place, so there isn't redundancy with multiple workflows. I think its needed. I also understand putting all of these dependencies in the data directory for Alfred. So, for Python the bundler needs to do 2 things: download/install Python packages load that package within some workflow script This seems to be what the PHP version does, right? But why "rebuild Pip"? Couldn't you just pip install the package and use the --target param to send it to the proper location within the bundle directory tree? I'm imagining a somewhat different set-up for Python. Instead of __load(), what if the Python version used __exists(), which you place at the top of the script. This function will check the bundler directory tree for the passed package names (you could pass a list of dicts, each of which could have bundler's 4 possible params). If the package is in the directory, the function simply returns True, else it leverages pip to install the package to the directory, and then returns True. Before the functions returns True, however, it adds the Python bundler path to the sys (sys.path.insert(0, $bundler_dir)). In the workflow's script, therefore, you could place the __exists() function at the top, before the importing (even wrap the script in an if... block). Then use the standard importing syntax to import any required packages. In this way, the Python section of bundler's directory tree would look and function like (for example) /Library/Frameworks/Python.framework/Versions/2.7/lib/; that is, it holds all of the packages or modules downloaded. Then you only need to insert the path to that directory to the sys.path. This makes sense to me, but what say you?

I quite literally dreamed about this last night. I have myself something like 6 workflows that I've written that all use Alfred-Workflow, and each one has it's own copy. I hate redundancy like this. Imagine a world where there was an Alfred-Workflow workflow, and you only needed to have that one workflow, but then all of your other workflows could tap into its functionality.... I'll go back to dreaming now.

It's just a matter of best practice for sharing workflows. There are certain things that make workflows easier for a wide array of users to download and use. As Vitor said, users would much prefer to download a helpful workflow (which this is) and have it work "out of the box". Many users don't understand and aren't interested in understanding the code under the hood, and won't want to or be comfortable fiddling with the internals of the workflow (how many wouldn't even know how to find the internals?). I've found that it simply kinder to simplify the workflow version that you share on the forums, and then customize your personal version. That works best for everyone.

Mid-Level Update: 2.3 Do you keep important reference PDFs in the same directory tree? Would you like a dead-simple way to hyperlink to PDFs from Evernote? Do you use the PDF viewer Skim? If you answer to each of these questions, this update will be for you. I personally have all of my PDFs in one directory tree, and I love interconnecting my data. In this update, I've applied the same logic used in the auto-link to pre-existing Evernote notes to PDFs, using a custom URL handler that I developed to utilize Skim's applescriptability to create hyperlinks that open PDFs! To use, you will need to change line 14 in the md2en.py script to the root folder of your PDF directory (this directory can include sub-directories with PDFs in them). After that, Wikify will auto-link to any PDFs in that directory tree that you reference by title in your note. Currently (I will fix this soon), you name the PDF file without the extension, tho the extension will be added to the hyperlink (for readability sake). I have yet to write a companion function for wfy to update current Evernote notes, so this currently only works on Markdown text you send to Evernote via mden. This is a niche function perhaps, but it requires no special syntax and could prove helpful (I like it). Let me know if you think this is helpful. (Teaser: keep your eyes out for the update to my Skimmer workflow for exporting PDF notes from Skim to Evernote using this same URL handler). Update on Packal.

Hmm... I actually think the non-user-facing abilities can be nice (à la David), as well as the "suite" abilities (à la Shawn). I personally have been tinkering with ways to create a suite of workflows that can work together, and I think that this feature will greatly help (tho I haven't been able to fiddle with it much yet, aside from the basic test case in the examples). For instance, I want to integrate the bibliography management capabilities of ZotQuery with the PDF abilities of both SEND and Skimmer without creating some massive, bloated workflow. Or, I'm currently working on integrating Zotero stuff with Evernote stuff, and linking my two workflows for those apps. On a note similar to Carlos's, I'm also thinking about the ways in which this can open up Alfred workflows as a software distribution platform. For example, in the past, if I put together a script I thought was helpful, I would make a Gist and let people grab it, save it, and use it as they please. But I got a fair number of questions on how to set the script up, how to make it executable (not in any Unix way, just in general), and how to integrate it's functionality into other workflows. Now, I'm basically packaging all of my "helpful" scripts as Alfred workflows, but a number of them have functionality that could be useful outside of the Alfred context and integrated into other, larger workflows on the Mac. For example, within my Wikify workflow is a script for document-specific snippets. Define snippets and their expanded text as you write, then post-process the text to expand. This works great for notes, where you don't know key-terms going in and you probably wont use those terms in great quantity afterword. I can now bundle my workflow such that a user who downloads it can access that functionality within another Applescript, which is doing something completely different from sending Markdown to Evernote for wiki-goodness. With a little tweaking, I can update the processing script to tell the difference between an internal workflow call and an external call, and output things differently in each case. I'm just spit-balling here, but I think that we could start to open up the more general functionalities that our various workflows have as "features" to be used in other contexts. For example, I could tap into Alfred-Workflows filtering abilities within some other project without having to copy over the code. At the very least, I for one am going to start thinking about my workflows somewhat differently, trying to articulate, isolate, and provide access to functionality in a workflow that I think could be more generally helpful. By opening up certain functions within our workflows in this way, I think we could find another level with which we could create truly interesting "workflows" where different things are glued together without simply copying code together and creating a whole new workflow.

UPDATE: Version 2.2 live on Packal with a small (but important) bug fix. Download and upgrade now.

Very nice. Thank you.

Version 2.1 utilizes Alfred's new app-specific keyboard shortcuts, so that enmd, ensel, and wfy are all dependent on Evernote being the app in focus. Also, one bug fix in the wfy script. Please update via Packal

MAJOR UPDATE Version 2.0 At long last, some full-featured wiki-functionality is here. Gone are the days of SearchLink-style syntax. Wikify now automatically will hyperlink to any pre-existing Evernote notes referenced by title in your note text. For example, let's say I was typing up a note with this content: # Note Title = Notebook @ tag1, tag2 This is the first line of my new note on Alfred App! Now, if I had a note in my Evernote account entitled "Alfred App", when I process this note to send it to Evernote, Wikify will now catch that and hyperlink to that pre-existing note, so this new note would have the phrase "Alfred App" linked directly to that other Evernote note. No fuss, no hassle, no funky syntax. And (this is what was holding me back on this feature for while), this is SUPER-FAST! Now, you can inter-link (i.e. wikify) your Evernote data even more easily. This feature is added on top of the in-text snippets feature from Version 1.2 (see above post), but replaces the SearchLink syntax feature. So, to create a new Evernote note with this auto-linking functionality, simply type up your note text in Markdown format in your text editor of choice, then either: select the text and use your user-specified key-board shortcut, or copy to the text and use the keyword mden (for "Markdown to Evernote") But this isn't even all of the new features. What if you want to interlink any of your current Evernote notes? You can use this auto-linking power for current Evernote notes as well. Simply open up Evernote and select the notes you want to wikify (the workflow does accept multiple selections). Once your notes are selected, pull up Alfred and use the wfy (short for "wikify") keyword. The workflow will then process each of your notes individually, auto-linking to any pre-existing other notes which it references by name. NOTE: In order to use this feature, you will need the Satimage OSAX Scripting Addition. I've set it up such that this is remarkably easy to install. Simply use the keyword in Alfred wfy:install and the Satimage installer will boot up and walk you through the process. But wait, there's more! While half of wiki-functionality is smooth linking to any pre-existing data, the other half is smoothly creating new spaces to fill with data later, while simultaneously creating the inter-linking between notes. Wikify has you covered here as well. Let's say as you're typing up a new Evernote note, you realize that you are discussing an idea, topic, or person that you want to research further, but at some later date. What to do? Well, you can use the standard wiki-syntax of the [[double brackets]] to mark that idea, topic, or person as something you want to create a new note for, while also linking to that new note from within your current note. To return to our sample note above, let's say you added this: # Note Title = Notebook @ tag1, tag2 This is the first line of my new note on Alfred App! I want to talk more about [[AppleScript]]. Whenever you have Wikify process this Markdown text and send it to Evernote, it will first create a new note (in the notebook you specify in the meta-data) entitled "AppleScript" then embed the Evernote hyperlink to that new note within this current note. This means that your new Evernote note will have 2 links: one to the pre-existing note "Alfred App" and one to the newly created, blank note "AppleScript". This functionality is bundled into the mden keyword script, so there's nothing new to learn here. However, let's say that you are in Evernote and see a phrase or term in one of your notes that you want to research more, while creating the wiki-environment that Wikify is all about. I've added a companion feature which will: take the currently selected text in the open Evernote note create a new note in that notebook whose title is the selected text embed a hyperlink back to the original note as the first line of this new note and replace the selected text with a hyperlink to that newly created note This means that you have two-way hyperlinking (which is impossible in the mden version of this functionality) between your current note and your new note. Creating spaces for new thought, while retaining context and wiki-style hyperlinking has never been easier. To use this feature, you can either use a user-specified keyboard shortcut, or copy the selected text to the clipboard and run ensel. I'm really excited about this new point release. I've been dreaming about creating these features for around a year now, and it's great to finally see them come to light. If you use Evernote much at all and like the idea about inter-connecting your data, I really think that this is the best possible collection of tools and scripts to make it as easy as possible. Let me know how you use it, I'd love to hear. stephen

Why not package the SearchLink.workflow file with the Alfred workflow, then call its internal location in the Applescript? This will allow anyone to use it, and likely save you some time with "bugs".

Ok. Well, ZotQuery is unable to locate any of your Zotero data, which is why it cant create the json database, which is why it isn't working. Which version of Zotero do you have installed? Zotero Standalone or Zotero for Firefox? We are going to need to find where your Zotero data is lurking to get things working.

Can you open the paths.json file in the storage folder (use z:bug and select "Open Storage Folder" to find it) and then paste in the contents? It appears that the script can't find your Zotero .sqlite database.

You are missing nothing. You found a bug. I have fixed it and uploaded version 7.1.1 to Packal. Update and rerun z:config. Things will work now. stephen

Ok. I've just posted version 7.1 to Packal. This should fix the multi-term query issues. Essentially, I "strain" the results for each term in the query string. So, to keep things as fast as possible, I would recommend putting the more specific term up front. I will think over ways to determine which term is most important, and maybe ZotQuery can reorder words for you. But for now, it will at least match multi-word queries with fuzziness. For example, the query "ein qmd" would match against "Einstein 1935 Can quantum-mechanical description of physical reality be considered complete?" using different rules on different runs. I'll continue to try to improve performance, but this should work well for a majority of users. stephen

Good point. Agreed.

Ok. Version 7.0.1 is now up. It fixes a small bug in the zot query affecting some users. Also, here's how to change the scope of the zot query. This will be a "power-user" feature, which will require altering the code. So know that up front. If you aren't comfortable with that, I would recommend getting more familiar and comfortable with the myriad of specific queries. But, to the issue: Open the zq_utils.py file in a text editor or code editor (I use Sublime Text, tho TextMate will also work. As will many others no doubt). You need to find the zot_string function (it should be at line 112). It will look like this (in version 7.0.1): def zot_string(d, scope='general'): """Convert key values of item into string for fuzzy filtering""" def get_datum(d, key, val): try: return [d[key][val]] except KeyError: return [] except TypeError: return [x[val] for x in d[key]] _list = [] if scope == 'general': _list += get_datum(d, 'data', 'title') _list += get_datum(d, 'creators', 'family') _list += get_datum(d, 'data', 'collection-title') _list += get_datum(d, 'data', 'container-title') _list += get_datum(d, 'data', 'issued') _list += get_datum(d, 'name', 'zot-collections') _list += get_datum(d, 'name', 'zot-tags') _list += d['notes'] elif scope == 'titles': _list += get_datum(d, 'data', 'title') _list += get_datum(d, 'data', 'collection-title') _list += get_datum(d, 'data', 'container-title') _list += get_datum(d, 'data', 'issued') elif scope == 'creators': _list += get_datum(d, 'creators', 'family') _list += get_datum(d, 'data', 'issued') elif scope == 'notes': _list += d['notes'] elif scope == 'in-collection': _list += get_datum(d, 'name', 'zot-collections') elif scope == 'in-tag': _list += get_datum(d, 'name', 'zot-tags') elif scope == 'attachments': _list += get_datum(d, 'name', 'attachments') _list = [unicode(x) for x in _list] _str = ' '.join(_list) uni = to_unicode(_str) return uni You will be changing the code under the if scope == 'general': section. This defines what data is included in the zot/z query. As you can see, it currently grabs most of the important data: title author(s) last name book/journal title pub date Zotero collection(s) name Zotero tag(s) name any notes This is clearly a broad swath of data. If you have alot of long notes, for example, this will decrease the searching speed, but might not be helpful to you. To change, you need only delete the lines that add those items. You can limit the scope simply by deleting any line(s) that add data you don't want.

UPDATE: Version 7.0 is now live on Packal. I have completely refactored the code for this version, opting for an object-oriented approach (which now allows me to have unit tests, yay!). However, the functionality is exactly the same, plus some. Nothing has been lost, only added. ZotQuery now deals with Group Libraries. By default, ZQ indexes and caches items in Group Libraries that you are a member of, you can, however, disable this feature. Items in Group Libraries will now open appropriately from ZotQuery as well. Dates have been added to the searches of the "general", "titles", and "creators" scope. Better, cleaner support of multi-term queries smaller code footprint For those power-users who want more fine-grained control, I will post later how to alter the code to change what all is searched with the zot/z keyword, as well as how to disable indexing of Group Library Items. Till then, go and update! stephen

I have it, I just haven't really used it yet. In the past, I would lazily save applescripts that I wanted to use as .apps, then just use Alfred's basic app search to find and then run them. But I've wanted to get things better organized for a while now.

This will probably be the thing that finally gets me to take all of my various Applescripts and actually put them in the appropriate App folders...