smarg19

It would appear that the problem lies with the placement of your findReplace handler within the "Run NSAppleScript" action. Here's how it should look: on alfred_script(q) set draftsPath to (path to home folder as text) & "jekyll:site:_drafts:" --set q to "This is a test draft" set linkpostTitle to q set linkpostFilename to findReplace(space, "-", linkpostTitle) set newDraft to draftsPath & linkpostFilename & ".md" set af to open for access file newDraft with write permission set eof af to 0 tell application "Safari" activate set linkpostURLTitle to name of front document set linkpostUrl to URL of front document set linkpostQuote to (do JavaScript "(''+getSelection())" in document 1) end tell write "---" & return & "title: " & linkpostTitle & return & "date:" & return & "layout: post" & return & "categories: []" & return & "tags: []" & return & "link: " & linkpostUrl & return & "---" & return & return & "> " & linkpostQuote & return & "from: " & linkpostURLTitle to af as «class utf8» close access af tell application "Sublime Text" activate open newDraft end tell end alfred_script on findReplace(findText, replaceText, sourceText) set ASTID to AppleScript's text item delimiters set AppleScript's text item delimiters to findText set sourceText to text items of sourceText set AppleScript's text item delimiters to replaceText set sourceText to "" & sourceText set AppleScript's text item delimiters to ASTID return sourceText end findReplace

Honestly, it will completely depend upon the app that you are pasting into. Some apps will automatically "sense" that the text is or contains a hyperlink and make it active (i.e. clickable). Others simply don't. Some allow you to specify that some text has a hyperlink. Its a crap shoot. As some examples, paste a plain text hyperlink into TextEdit. It will become active. Paste the same plain text hyperlink into Evernote. Nothing will happen, tho you can make it a link. Then try pasting it into a plain text editor like Sublime Text; nothing happens. So, tl;dr: you need to understand how exactly the app(s) you want to paste the hyperlink into work with hyperlinks. This will make your task at least much more understandable.

OK. I should have a solution in version 2.2.1, which I've just pushed to Packal. It appears that Evernote renames the temporary directories to temp_dir.backup after you fiddle with the PDF. So, my new URL handler will try the original Evernote path, but if there is an error, it will try the .backup path instead. So, you will see the same dialog box saying that the file doesn't exist, but if it does actually exist, once you select "Ok", it will open the PDF.

Ok. This is actually a problem with Evernote. It's a bit convoluted, but essentially Evernote will move your internal PDF every time that you open it and/or annotate it. So you open it once, and it puts it in path path/to/pdf/x, then you export the annotations where the links are are to path x. However, it only lives in path/to/pdf/x temporarily, so when you go and click those links, nothing is there. Thus the error. In order to fix this right now, you will have to keep a local copy of the PDF (i.e. not in Evernote). I will investigate if there is some way for me to find a stable location for your Evernote pdfs.

Can you copy a URL from the synopsis and paste it here? Thereby be a bug in the URL forming which isn't allowing them to be properly decoded

This is a somewhat odd error. It means that this text file is encoded oddly. Can you open up Terminal and use this command to try and see the character encoding for thatInstructions.txt file: file -I {filename} For {filename} put the full path to that file.

You're right. This is bonkers. I'm reading up on it all now, bit I think this is a solid foundation. I'll need to do lots of fiddling to optimize this setup for ZotQuery. The original Zotero data is already in a SQLite database. I wrote a script to translate that to JSON so I'll need to figure out the most efficient way to get the key SQLite data into the FTS virtual table. I could also see how a Pythonic wrapper for this core functionality could be a nice addition to Alfred Workflows. I'm def going to pursue this course of action, so thanks for the point in the right direction

One thing I'm still a bit confused on is the Whoosh schema. It appears that there is no way to nest fields (as in a JSON array of dicts for the value of a key. How do I store a list of item creators in Whoosh?

For what it's worth, here's how the script should look if you put it into a "Run NSAppleScript" action: on alfred_script(q) set query to q as text set astid to AppleScript's text item delimiters set AppleScript's text item delimiters to {"."} set front_string to text item 1 of query set back_string to text item 2 of query --Reset ASTID set AppleScript's text item delimiters to astid --Paste first part tell application "Microsoft Word" set the clipboard to front_string activate delay 2 tell application "System Events" to keystroke "v" using command down delay 2 set the clipboard to back_string activate tell application "System Events" to keystroke "v" using command down end tell end alfred_script

Unfortunately, this looks like too much of a learning curve at this stage. I think I'll go with the caching right now, since I know how to implement that. On search indexing, have you ever heard of/used Whoosh? I've been reading up on it. It's a pure Python search library.

That's odd, because I've made a test workflow and it works just fine. Try downloading my test workflow. Look at the script and test it out using the `tester` keyword. (Make sure you have a Microsoft Word document already open). Let me know how that goes. https://www.dropbox.com/s/r4t68cxcn3qj4vf/tester.alfredworkflow

What exactly would you recommend? An inverted index? Or both a forward index and an inverted index? Something else? I've started reading up on search indexes, and there are quite a few possibilities. Also, how could I make this work while keeping the various search types that ZotQuery uses?

Here's a possible rewrite of your code: on run argv set query to argv as text set astid to Applescript's text item delimiters set AppleScript's text item delimiters to {"|.|"} set front_string to text item 1 of query set back_string to text item 2 of query --Reset ASTID set Applescript's text item delimiters to astid --Paste first part tell application "Microsoft Word" set the clipboard to front_string activate delay 2 tell application "System Events" to keystroke "v" using command down delay 2 set the clipboard to back_string activate tell application "System Events" to keystroke "v" using command down end tell end run

As Vitor said, more information is better. But here are some general thoughts on the code posted: ALWAYS reset Applescript's text item delimiters. If you don't, that will carry over to other scripts (which is bad, bad, bad). Use a more unique delimiter in your input. A period (".") is far too generic. Since I don't know exactly what types of things are likely to be input, I can't be more specific with suggestions, but in general, you want to concatenate using something that wouldn't otherwise be in a string (e.g. "|.|"). You have slightly misunderstood how ASTIDs work. You can't set them globally and then ask for text items of argv. Here's sample code that properly uses ASTIDs: set query to argv as text --Save default value of ASTID for later reset. set astid to Applescript's text item delimiters --Use a unique delimiter set Applescript's text item delimiters to {"|.|"} --Split the query string, not the argv list set front_string to text item 1 of query set back_string to text item 2 of query --Reset ASTID set Applescript's text item delimiters to astid --Now you can use front_string and back_string as needed

Ah, so you're suggesting that there be multiple filter caches? Sort of like your frequent searches, so that if you search for that thing again, ZotQuery will be faster. I was initially planning on just having one cache to speed up only the present search, but this set up could also work. In general, I'm trying to intelligently improve performance via caching in a few places. I'm almost done with a system for caching export results, so that exporting something the second time will not require an internet connection and will be instantaneous. I think that caching search results is an equally good idea. I'll test and investigate, but right now, here's my thought: When a query is initiated, ZotQuery (1) checks to see if there is a cache for that query (I will save query filter results under the query name). If there is a cache, return those results (this is the speed up for frequent searches situation). If there isn't, (2) check for a recent cache (this is the speed up slow typing situation). If there is, (3) check that new query starts with that recent query (so old query cached results filtered on thom, and new query is thomas). If it does, (4) filter new query against cached data only (not full data set). If no to any of 1-4, then filter new query against full data set. In your cache folder, things would look like this: there would be a number of files for past searches; these files are named [query].json. There is one file called recent.json where the last search is stored. (There are also other files pertaining to the actioning processes, but those aren't important here). I can have functions to (1) delete all files when database is updated or (2) delete all files when cache dir exceeds some space limit (this limit will be hardcoded, but easily altered by user). Right now, my thought is to check the cache dir size alongside the check for whether or not to update the database. So that process will look like: (1) Is database up-to-date? If yes, do nothing; if no, update and delete cache. (2) Is cache dir appropriate size? If yes, do nothing; if no, delete cache. This will all be in one function called after each ZotQuery action (i.e. when you export or open something). Any thoughts or suggestions for this course of action?

I'm not sure what's up. I've tested a few things, and it's working well for me. Without that error message, I'm not sure I can guess at what the problem is.

Can you run the workflow with Alfred's debugger on. To turn this on, open Alfred, go to the Workflows tab, find SEND, then click the bug icon in the top right corner. Then attempt to run this workflow and paste the debugger's output here. That will greatly help me track down the problem.

This appears to be an issue with Gatekeeper settings. To be honest, Gatekeeper is a real bugaboo. I've tried to set things up to circumvent this, but it's quite complicated. Did this error only pop up after you added the copy to clipboard? If so, the simple reason is that there is nothing to copy. Could you remove that option and try to run the workflow as is with the debugger on and report that error?

Whenever I open the GUI, the `viewer.app` window is too skinny.

Would caching search results with a lifespan of ~2 seconds achieve this result? When Alfred calls the search filter, it first checks for the cache. If it's there, filter from that data set. If it's not, filter from the full data set. Obviously this would mean you couldn't run different queries within 2 seconds of one another. But that may be a worthwhile trade off...

You can use the Spritz bookmarklet to speedread any webpage using this technology. Check out the official Spritz bookmarklet here: http://www.spritzinc.com/where-can-i-experience-spritz/ That would work with Instapaper articles (viewed online) as well as Pocket, or any webpage whatsoever!

Glad that fixed everything!

Since the bundler isn't my area of expertise, I'm not entirely sure what the problem is. But I suspect it may be a minor versioning issue. Try going to $USER/Library/Application Support/Alfred 2/Workflow Data/alfred.bundler-aries and deleting that entire folder (that is, the alfred.bundler-aries folder). Once it's deleted try to run that test_space.py code again (also, you can delete everything in that code and just paste in these two lines: from workflow import bundler print bundler.utility('viewer') The other stuff in that code is unnecessary. It will take a bit of time for the bundler to install itself and get going, but hopefully a fresh start will get things working properly.

Hmm... I'm using the Alfred Bundler to get this utility, and I'm not sure why it's not downloaded. It should download on the first run (so the first run takes a bit of extra time), but then should work smoothly from then on.Could you open the workflow folder, open the test_space.py in an editor and just paste this code in then run it. Tell me what happens then: from workflow import bundler bundler.utility('viewer') This is what should download the viewer app.

Spritzr an Alfred Speed-Reading workflow Current Version 1.0 Available on Packal Spritzr is a relatively simple workflow that allows you to speed-read text on your Mac using Spritz-style techniques. The simple idea is that one word of your input text is displayed at a time in quick enough succession that you are no longer Sub-Vocalizing, which is the largest impediment to reading at a comfortable, yet swift pace. The added layer of nuance, however, is that each word is positioned around the so-called Optimal Reading Position. To borrow an image from the Spritz website, the difference between most electronic speedreaders and Spritz-style speedreaders is the alignment of the words: This workflow achieves a similar affect, thus making reading simpler and faster. NOTICE: I wrote all of this software from scratch and have no affiliation with the Spritz company. I was inspired by other open-source projects that attempt to mirror the Spritz functionality: OpenSpritz and spritz-cmd, but this software bares no relation to Spritz aside from appearances. Spritzr currently only has one command: spritz. This takes text input which will be parsed and displayed in the Spritzr window. Alternatively, you can pass text files (.txt, .md, .mmd) into Spritzr using the File Action File Spritzr. This will parse and display the text content of that file in the Spritzr window. There are two settings, which can be changed using the spritzr:set keyword: Words per Minute Reading Mode If you which to change your wpm, simply invoke spritzr:set and input an integer (the default is 250). If you which to change the reading mode, invoke spritzr:set and input either dark or light (the default is light). Dark Mode: Light Mode: Other than that, you can just start spritzing!