Toffy

I'm am the latest version of Ventura. I did not do a fresh install or any migration in the past two years but I install the macos updates as they come. I use TimeMachine to back up but so far never needed to restore anything (fingers crossed). Yes, I read about that, but that is not the behaviour I'm seeing. I open that folder about once a month and I never open any of those Zotero folders but they still rank higher. Maybe the problem is that even though I definitely open the IR folder regularly, I may not be doing so by directly clicking on a search result, for the simple reason that there is no search result to click on (because the Zotero folders as well as some other folders containing IR are ranked higher and the number of hits is limited). So it's a vicious circle... While that looks like a convenient explanation, I'm not sure this is the whole story because I believe that I at some point somehow did get the IR folder in the search results and clicked on it. That single click should have been enough to make sure it ranks top in any future search... But putting the above aside for a moment: wouldn't you agree the an exact match should always rank higher than a partial match (all else equal)? I think the fact that this is currently not the case is the core of the problem.

Thanks for your assistance. I'm glad that this may have been an issue with Alfred and not with Spotlight (which would probably have been much more difficult to resolve). Unfortunately, that doesn't work as a test because I was already able to find it before making those changes. That is the tricky thing with troubleshooting this issue: 1. I search a file but Alfred doesn't find it. 2. I find it using GoToFile (sometimes I even manage to retrieve the location from my brain!) 3. Since I already wasted my time trying to find the file, I rarely want to investigate the issue more, but when I do, like today, Alfred troubleshooting often fails to find a problem and I had the impression that it was due to me navigating to the file, that some forgotten part of the index got reactivated. Previously, I tended to doubt my memory (also because this reactivation theory is nonsense). Did I really search for the correct term? Did I get too many hits and failed to search through them all? etc. There are many ways humans err and if I can, I try to blame it on the human rather than the machine. But this time it was different (as explained in the OP). There was no way of blaming it on the user. So. let's hope that the full disk access fixed it (although I didn't migrate or upgrade other than the regular macOS updates). Just one question: does full disk also include everything mounted under /Volumes (like external drives and network Volumes) or do I need to re-add those separately? Oh, and while I'm at it: another thing that keeps bugging me is that whenever I search for a folder named "IR" (the name of a committee on which I sit), Alfred presents me a long list of Zotero storage folders (which are named with random combinations of letters and numbers) that happen to contain the letters IR. Strictly speaking, it's not wrong to present IR6G6NM7 and VMV7R4IR as hits for that search ... but when there is a folder that matches the search string 100%, I see no reason why it would not be placed at the top of the search results. I think it's called "Levenstein similarity" or something like that. Doesn't Alfred use that? I have to say, when I just tried the search the results looked better than before. It was not just Zotero storage folders, but the actual IR folder was still ranked #9. So perhaps the all-disk thing also contributed some improvement to that thing, but the basic question remains: why doesn't the exact match not show up on top of the list? I tried disabling Fuzzy search (although I appreciate it otherwise), but the results are identical.

Here is the full troubleshooting file, I only modified the file name for reasons of confidentiality. The modification consisted of replacing numbers with other numbers. I am aware of the problems that "online-only" storage can cause, which is why I have this feature disabled, both on iCloud and on Dropbox. Selective Sync is also disabled.

I'd like to file this as a bug report, but since I can't (haven't tried to) reproduce this, I'll just submit it here as a question/ observation. Generally, I'm having trouble getting Alfred to find all my files and folders, but I know that this is not a problem with Alfred but with Spotlight, especially when it comes to indexing files on a Samba share. The problem I'm describing here does not involve Samba, but chances are that it is nevertheless a problem with Spotlight. But I hope to get some help with it anyway. The following happens occasionally when I search for a file name or folder that I know exists but Alfred just won't show it in the search results. I then use GoToFile to locate it (if GoToFile were a bit faster and if I could get my muscle memory to switch to a different shortcut for file searches, I'd always use GoToFile). Today I searched for a folder called "Voluntas", a unique name that doesn't show up anywhere else on my system, no file or folder has it as a component of its name. Alfred did not find it. GoToFile did without issues. I then dropped a file from that folder into the Alfred Troubleshooting modal to see why the search failed. But the result was all green: ✅ File cache integrity is ok ✅ Alfred has permissions to read this file. ✅ Indexing is enabled on this drive ✅ Direct metadata available ✅ Metadata contains required items ✅ File exists within Alfred's default search scope ✅ macOS returned a match for this file in your search scope. ✅ Troubleshooting passed So, I opened Alfred again and searched for Voluntas and this time it found it. I have no idea how this is possible. You may think: "You made a typo the first time you searched." I'm confident to say that I did not because I checked. But even if I still spelt Voluntas wrong, the same problem exists with the parent folder ("reviews"). This was actually the first folder I search for but since Alfred showed me various files and folders containing "reviews" it did not show me the folder containing the voluntas folder. That's why I then searched for a more unique folder name, just to make sure that I'm not missing the result in the list of non-relevant results. My best explanation for this behaviour is that the folder got indexed because I accesses it. But why wasn't it indexed before? The folder has existed for several years and while I have not accessed it for years, I would expect it to remain indexed. Is this just another example of Spotlight being very unreliable in doing its job? How do people deal with this? Finding files is one of the most basic and most important things we do on a computer and yet macOS is not able to do it properly? I'm still hoping that I missed something and when I fix that, it will work...

That’s a decision, not a bug. It’s quite common for case converters to make that choice, because otherwise acronyms get mangled. A way to work around, if you know your text doesn’t have acronyms, is to lowercase first then title case. OMG, thanks for clarifying this. This behaviour was driving me nuts. I kept checking the config, uninstalling and reinstalling the workflow... I didn't realize this behaviour was specific to all Caps because all Caps is all I use the workflow for. IMHO it makes more sense to let the converter treat acronyms wrong (and the user fixes it manually) rather than not doing anything at all. Or here is a suggestion: If I understand it correctly, workflows doesn't touch words that are all Caps, right? My use case is that I often have the entire text all Caps and I'd say at least for that case it makes sense to make an exception to the exception and apply title case. So: if single words are all Caps, OK, leave them alone. But if the entire text (or, say more than 90 percent) is all caps, then apply titlecase anyway.

I am also looking for this kind of functionaliuty. I was hoping that you could maybe add multiple, comma-separated keywords into the keyword field, but unfortunately this sis not possible.

I’m totally new to automation tasks, but from what I can see, “Set Window Bounds from Preset” does not allow me to specify a window size of, say 1700x600 for a 4K screen or 650x300 for an HD screen, does it. I can (an do) however, use it to center the resulting window.

I found an automation task called "Set Custom Window Size" which I would like to use in a workflow. To make the workflow more robust for different screen resolutions, I would like to check for the current screen resolution and then set the window size based in that. How can I determine the current screen resolution?

Zotero creates randomly named folders in its storage folders. These folders (and similar ones from other apps) regularly mess up my search results. For example, when searching for the folder ~/Documents/3D, it gave me this: I am not sure why these folders always seem to rank high in my searches, but it could be because these folders contain pdf documents that I often search for and my understanding is that Alfred prioritizes paths that are often selected. This is good, but I like to exclude these folders from any search results while not excluding the folders' contents. I know how I can increase the search scope in Alfred Preferences under Default Results, but how do you reduce the scope? And how do you do it so selectively as I need it? I have looked at filtered searches, but I couldn't figure it out. It doesn't seem to be possible. Is this so?

Done.

Thanks! Note that it should say "commas" instead of "colons".

Could you share your workflow? I looked at the Youtube control workflow but couldn't figure out how to adapt it to get the current timestamp...

Keywords in academic articles are usually separated by semicolons or commas but if you try to copy and paste these keywords into Zotero (and possibly other reference managers), the whole list will be converted into a single tag. In order for Zotero to create a separate tag for each keyword, each keyword has to be in a line of its own. In other words: semicolons/ commas need to be replaced by linebreaks. And that's exactly what this workflow does. The workflow provides two ways of achieving the same thing: You can copy the keywords the normal way (⌘+C) and then use the assigned hotkey to paste them, or You can copy the keywords using universal actions (Select "Replace semicolons and copy") and then paste them the normal way (⌘+V). Either way, semicolons will be replaced by linebreaks. So replacing semicolons is the default behaviour but in both cases, you can use the option key to replace commas instead of semicolons. Note: this is my first workflow and I'm sharing it here partly because I'd like to learn how the workflow could be optimised (I went for the first solution that came to mind, and I have little to no knowledge of the tricks and tweaks that can be achieved with Alfred Workflows. So feel free to improve it and share a new version here. The workflow file is here: https://github.com/tophee/alfred_workflow-replace_semicolons/blob/main/Replace semicolons with linebreaks.alfredworkflow

This is the most hidden feature I came across in a long time. It even remains invisible once you use it 😉 My experimenting did go as far as just hitting enter in the field on the right, but Alt-enter didn't occur to me. Thanks for sharing this here!

I'm trying to understand whether what exactly re-installing python 2.7 based on these instructions does. I understand that it will bring workflows relying on python2 back to life. But does it also break workflows relying on python3, i.e. can I either use python2 workflows or python3 workflows, or will both just work fine?

@Andrew I'm glad I finally found the solution here, but I wonder: why doesn't Alfred use the same file trees that it knows from file search? The least I would expect is that it starts looking there when it doesn't find the search string in the default search scope... In case this is already the expected behaviour, here are the specifics of my case where it definitely didn't work like that: 1. select a file A in the download folder 2. Use shortcut to trigger file action menu I want to move file A to /Volumes/together/home/clubx (a samba share on my local fileserver) That path is indexed and shows up in file search as expected 3. Type clubx in the file action menu -> nothing found 4. Type home in the files action menu -> nothing found 5. Double check if clubx is really indexed by dragging the folder into the troubleshooting space -> confirmed that it is indexed 6. Follow your instructions above by typing /Volumes/together/home into the file action menu and then selecting clubx 7. After that, typing clubx will immediately bring up that folder in the results.

Does this work when moving to a different volume? Also, drag & drop can be laborious, so I'd much prefer something like cut & paste on Windows. Which is, why I really like the Alfred file actions. It does that and much more. But not across volumes. I guess when you're on Mac, there is no way around the patronising Apple way...

I'm wondering about the same. It's so weird that the finder doesn't have an option to move files so I was happy to find that Alfred provides this but now it turns out it's also just copying...

Assume we have a file ~/Dropbox/meeting-feb20.pdf Alfred will find it if I search for pdf meet or meet feb but it will not find it if t search for drop meet i.e. when I'm searching for part of the path, not just the filename. Is there any way of searching in the entire path so that Alfred will find the file above when searching for drop meet (for exempel)?