TheBloke

Hi all Recently I've found that I have a regular requirement to drag a recent document to the software I'm currently in, for example a web browser, or Discord. To achieve this, I bring up Alfred, type <space><document name>, then take one hand off the keyboard and move it to the trackpad to drag that document into the app. This is OK, but I'd love if there was some action I could add to Alfred to automate the 'drag to current app' part. I want it to automate the process of dragging and dropping the selected file into whatever app I was in when I brought up Alfred. Then I could do the whole process with keyboard alone. Is that possible? Thanks

Yeah, after I re-enabled spotlight, all my apps reappeared in Alfred. I also have had huge cpu usage from spotlight processes constantly since I enabled it, which was the reason I disabled it in the first place. Maybe they will go away in time, but I had them for hours yesterday so I disabled spotlight because I thought why bother indexing things in spotlight when I exclusively use Alfred.. OK I will just have to hope that the high cpu from spotlight goes away, or that I can diagnose its cause separately. I hadn't noticed it before yesterday when suddenly it became really bad, so maybe the indexes got damaged yesterday and it will just take a whole to rebuild then it will be OK. I did have a couple of unexpected reboots yesterday so I suppose that may have triggered something. Thanks

I think I know what it is. Yesterday I disabled all Spotlight indexing by adding my system drive to the exclusion list. Mdls sounds like a spotlight command. If you rely on spotlight to check metadata,it won't work if spotlight is completely disabled. I will test this when I'm back on the computer. If true it's annoying that it's required to keep spotlight running just for alfred to work, I disabled spotlight because I have alfred. Unless alfred hasn't implemented it's own indexing because it relies on spotlight?

Hi Vero Did you see the second half of my post? Right now I have no apps at all indexed in Alfred. Since I ran 'reload', no App or PrefPane is in Alfred's cache, including all my usual apps in /Applications/ I downloaded your MetaData tool and ran it on /Applications/iTunes.app, and it said exactly the same thing as on the command line: Is something broken on my OS?

I have restarted Alfred multiple times, and I just ran a reload as well, and it's still not picking up /usr/local/Cellar/8.0-145/MacVim.app despite /usr/local/Cellar/8.0-145 being directly in the Search Scopes I've tried mdls but it says it can't find any App I try it with - I don't know if i'm running it right? tomj@Marvin /usr/local/Cellar/macvim/8.0-145 $ mdls /usr/local/Cellar/macvim/8.0-145/MacVim.app /usr/local/Cellar/macvim/8.0-145/MacVim.app: could not find /usr/local/Cellar/macvim/8.0-145/MacVim.app. tomj@Marvin /usr/local/Cellar/macvim/8.0-145 $ mdls /Applications/Alfred\ 3.app /Applications/Alfred 3.app: could not find /Applications/Alfred 3.app. But I mentioned before that I did a Get Info and the MacVim.app shows the right UTI bundle information, and of course works when double-clicked in Finder. Actually, I just realised that since I ran 'reload', Alfred can't find anything! Or at least, any apps. Something is very wrong, I can't load any app at all now Here are my scopes:

I have MacVim installed via Homebrew. This currently installs MacVim.app as /usr/local/Cellar/macvim/8.0-145/MacVim.app. This directory is then symlinked to /usr/local/opt/macvim such that /usr/local/opt/macvim/MacVim.app is always pointing to the latest version. /usr/local/opt/macvim/MacVim.app is then further symlinked to /Applications/MacVim.app, meaning I always have an /Applications/ link to the latest version of MacVim.app. The problem is that Alfred does not detect /Applications/MacVim.app as an app - it never appears in the search results. I don't know if this has always been the case or not. However up until tonight I was able to open MacVim via Alfred, because it had in its cache /usr/local/Cellar/macvim/8.0-144/MacVim.app (the true location of the version I previously had installed.) Sure enough, I see /usr/local/Cellar is in my Alfred search scopes I don't know if this was added by default, or if I added it myself years ago. But I've now removed that old MacVim version, and Alfred is not now picking up the new install (/usr/local/Cellar/macvim/8.0-140/MacVim.app) even though /usr/local/Cellar is in my search path. I even tried adding /usr/local/Cellar/macvim, /usr/local/opt and /usr/local/opt/macvim as further search scope entries, but this didn't help. I then even added /usr/local/Cellar/macvim/8.0-145 to Search Scopes, so now the exact directory that contains MacVim.app is in scopes and it still won't appear! I am not sure if Alfred actually follows App symlinks. Another example of a Homebrew symlink is /Applications/IDLE.app which links to /usr/local/opt/python/IDLE.app, where /usr/local/opt/python is a link to /usr/local/Cellar/python/2.7.14_3. Alfred does show IDLE, but it shows it on the latter link, in Cellar. But then I tried removing /usr/local/Cellar from my scopes, and Alfred still shows IDLE (even after closing and reopening), suggesting it must be following the /Applications symlink, even though it shows it at its real location, not the symlink it (presumably) found it via? That's good. But in the MacVim case, it still won't pick it up at alll, whether by /Applications or a direct search scope of /usr/local/Cellar, /usr/local/Cellar/macvim or even /usr/local/Cellar/macvim/8.0-145. So clearly there's something it doesn't like about this MacVim.app - but what? Something's changed at some point, given it previously picked up /usr/local/Cellar/macvim/8.0-144/MacVim.app but won't now pick up /usr/local/Cellar/macvim/8.0-145/MacVim.app. And no symlinks are involved there at all. I have confirmed that /usr/local/Cellar/macvim/8.0-145/MacVim.app has the UTI of com.apple.application-bundle. And of course it opens fine when double-clicked from Finder/Path Finder. Thanks. Directory listings: tomj@Marvin ~ $ ls -al /Applications/MacVim.app lrwxr-xr-x 1 tomj admin 32B 21 Feb 03:52 /Applications/MacVim.app -> /usr/local/opt/macvim/MacVim.app tomj@Marvin ~ $ ls -al /usr/local/opt/macvim lrwxr-xr-x 1 tomj admin 24B 21 Feb 03:51 /usr/local/opt/macvim -> ../Cellar/macvim/8.0-145 # no symlinks involved in the /usr/local/Cellar/macvim/* paths tomj@Marvin ~ $ ls -ald /usr/local/Cellar drwxr-xr-x 86 tomj admin 2.7K 21 Feb 01:38 /usr/local/Cellar tomj@Marvin ~ $ ls -ald /usr/local/Cellar/macvim drwxr-xr-x 3 tomj admin 96B 21 Feb 03:51 /usr/local/Cellar/macvim tomj@Marvin ~ $ ls -ald /usr/local/Cellar/macvim/8.0-145 drwxr-xr-x 8 tomj admin 256B 21 Feb 01:27 /usr/local/Cellar/macvim/8.0-145 tomj@Marvin ~ $ ls -al /usr/local/Cellar/macvim/8.0-145 total 32 drwxr-xr-x 8 tomj admin 256B 21 Feb 01:27 . drwxr-xr-x 3 tomj admin 96B 21 Feb 03:51 .. drwxr-xr-x 3 tomj admin 96B 21 Feb 01:27 .brew -rw-r--r-- 1 tomj admin 896B 21 Feb 01:27 INSTALL_RECEIPT.json drwxr-xr-x 3 tomj staff 96B 21 Feb 01:27 MacVim.app -rw-r--r-- 1 tomj staff 747B 18 Feb 03:55 README.md -rw-r--r-- 1 tomj staff 4.8K 18 Feb 03:55 README.txt drwxr-xr-x 15 tomj admin 480B 21 Feb 01:27 bin tomj@Marvin ~ $ ls -al /usr/local/Cellar/macvim/8.0-145/MacVim.app total 0 drwxr-xr-x 3 tomj staff 96B 21 Feb 01:27 . drwxr-xr-x 8 tomj admin 256B 21 Feb 01:27 .. drwxr-xr-x 9 tomj staff 288B 21 Feb 01:27 Contents tomj@Marvin ~ $ ls -al /usr/local/Cellar/macvim/8.0-145/MacVim.app/Contents total 136 drwxr-xr-x 9 tomj staff 288B 21 Feb 01:27 . drwxr-xr-x 3 tomj staff 96B 21 Feb 01:27 .. drwxr-xr-x 4 tomj staff 128B 21 Feb 01:27 Frameworks -rw-r--r-- 1 tomj staff 64K 21 Feb 01:27 Info.plist drwxr-xr-x 3 tomj staff 96B 21 Feb 01:27 Library drwxr-xr-x 5 tomj staff 160B 21 Feb 01:27 MacOS -rw-r--r-- 1 tomj staff 8B 21 Feb 01:27 PkgInfo drwxr-xr-x 94 tomj staff 2.9K 21 Feb 01:27 Resources drwxr-xr-x 11 tomj staff 352B 21 Feb 01:27 bin

Actually, thinking about my Google Drive issue - if you did implement multiple stores, and put them in different database files rather than just different tables, that would help a lot with keeping them synced to the cloud. One SQLite file for <= 3 months, one for >3 months. Then the former would remain small and would be quick to sync each time it updated. The latter would take longer, but it would only change once a day (presumably Alfred would handle this migration asynchronously and only periodically.) I do agree with mawek that it would be nice to have the option right now, with whatever warnings/"Advanced User Only" flags might be necessary. Or what about making it a command-line only option? Requiring a PList edit. I've seen other apps do that - don't add features to the UI, but put on a Wiki somewhere how to toggle from the CLI. That solves the problem of users just turning it to "forever" then complaining; they won't even know it's there unless they see this thread, or go looking for an answer. However if it has to be done with architectural changes, I can at least see one benefit - cloud syncing. At least if it's done with multiple SQLite files rather than tables.

Thanks very much for the response and explanation, Andrew. Personally I would be perfectly fine with taking my chances with having increased CPU, and battery is no concern on my desktop. Hence my mention of a warning when the feature was enabled, so that we could potentially get the feature quicker for those who don't mind potential downsides, and the warning would keep away those who do worry about that. I don't know your code of course, but I do know that other software is able to manage very large data sets in SQLite with no problem. My Ditto database is now nearly 2GB, and I perceive no slowdown on Control-C, nor excess CPU usage. It simply does an INSERT(..) to its SQLite tables for each new copy, and lets SQLite handle the indexing. SQLite is fine with far larger databases than this. I think Ditto does its purging of old data, beyond the expiration threshold, asynchronously (once an hour or once a day) so as not to add any extra load to each copy. I'm on a fast SSD which does help of course. The only problem I get with that huge Ditto DB is that I've put it on a Google Drive synced folder, so it's backed up, and that sync now takes a long time. But of course that's primarily because Ditto doesn't allow different storage periods for Text vs Images. If it did, I reckon my DB would be no more than a couple of hundred MB, which is trivial. So while I do understand and respect you wanting to absolutely ensure performance and scalability, my personal experience is that other clipboard managers are able to handle it fine using the same DB backend as you use, and without needing to archive to multiple, date-based tables. If anything I would have thought it would be easier in Alfred, given its (smart) distinction between Text and Image. Anyway I don't mean to tell you your business. I'm pleased to hear that it's on your radar, even if we do have to wait a bit longer. I lost all my prior clipboard history when I came back to my Mac after >3 months away, so I'm starting from scratch. But that does mean that if the new release happened within the next 3 months, it wouldn't make any difference to me anyway Thanks again for the fast response, and all your great work on Alfred.

I'm a long term Alfred user, but somewhat on-and-off-again due to my coming in and out of using macOS. I'm now back in macOS and hopefully for a good while now. And I signed up at this forum specifically to post this feature request, which has been one thing that's bugged me about Alfred's Clipboard feature since I first stated using it in 2012 or so. On Windows I use Ditto and I have my expiration set at 12 months, but that was only for space considerations as Ditto doesn't have Alfred's ability to give different time limits to text versus image data. If it did, I would set Text to "forever". Why not use snippets? I do. But the point of the forever history for me is to retrieve things I didn't know I needed to make a snippet. "What was that long command I ran on server X last year? I can't access the server but I know I copied it at least once.. it started with.. <SEARCH> that's it!" This doesn't happen every day, but it does happen periodically. I've pulled long-ago copied data out of my Ditto clipboard history many times. Sometimes I even need to browse through dozens of results, eg if I'm looking for a phone number I thought I'd only need once, and all I have to search for is the first two digits, 07. But I can very often work out the right entry by looking at the date it was copied. The important thing is that I have the option, and in practice I've found it very useful. I don't want to have to think, every time I copy something, "should I make this a snippet just in case I need it in 9 months?" And more often or not I have no idea that I'll need it again, until I do. I have my shell history (Bash and ZSH) set to never truncate for exactly the same reason, and that is regularly invaluable. Beyond that, I honestly don't understand the reason not to add the option? The default will always be low; 1 month or whatever it is now. Only people who actually want longer need set it, and as they have the flexibility to only do so only for Text, there's really no space worries. So I have to say I find it surprising and a little disappointing that there appears to be so much resistance to implementing such a simple feature. Lots of people are asking for it. It's surely easy to do. And it need not affect anyone who doesn't want it. Why not put it in? If there's some technical limitation - Alfred gets really slow when there's too much history, perhaps? - then just put a warning up and let us take our own chances with it. But if you're using SQLite or similar I really can't imagine there'd be a problem - it's certainly not for Ditto, which searches a huge DB just fine. At the moment I am regularly checking every new clipboard manager that I discover to see if it can replace this part of Alfred, and give me the forever history that I want. I just wish I didn't need to and could forget about it and just always use Alfred, which is perfect in most every other way. Thanks very much.