sylumer

There are no auto-update features built into any of the workflows. Bypass contains an exported AppleScript application bundle, so if you view the package contents you can view the details, and you can open it in Script Editor and view the (simple) script and additional bundle details. That bundle contains a binary generated by Script Editor when saving an AppleScript as an app. Note: As per the readme, the workflow's home page was changed a while back to https://thoughtasylum.com/alfred/alfred_slink_for_searchlink/ I don't know why that would be. My web site is hosted on GitHub and is served as a standard GitHub Pages site (using Jekyll - a standard for static site generation for GitHub Pages). Because I often schedule blog posts for future release, I have a daily rebuild trigger (07:00 GMT/BST). If the ETag regeneration was happening daily, I would say it is just GitHub refreshing its cache with each site build (while it wouldn't rebuild the workflow file as it isn't a page, it would rebuild the site folder structure from which the site is served). Since it is only "on occasion" that you have observed the behaviour, then there is nothing that comes to mind that I have configured that could be causing that. While I found an old StackOverflow post that indicates, at that time, Github Pages do not support ETags... https://stackoverflow.com/questions/25230195/html-etags-and-github-pages I subsequently found some newer pages that indicate that it does. https://w3techs.com/technologies/segmentation/cm-githubpages/site_element https://retirednotout.uk/blog/2021/05/cache-control-for-github-pages I don't know if any of that helps you?

v1.2.0 now available. Details in change log on its home page.

The way it shows up with the checkbox against the title was logical and in effect was restating. Knowing the label is being used by screen readers and would not otherwise be associated sequentially is useful o know and I will update accordingly. I don't think I'd even looked for options like that as this was written long before the new config was available and I was just dealing with text strings. I'll modify to include that for a better experience.. It may not work for all setups, but most text editors take a path as their first optional parameter on the command line - it has always worked with my text editors. However, I agree it isn't best practice and I'm happy to modify to use `open` instead. When I first created this workflow (several years ago), I experienced problems with Alfred not pasting the content reliably to the foreground app. This was a workaround that seemed to give me reliable results at that time. I realise that things have improved, so I'll review and update accordingly. I'll add those in, but most users of SearchLink have probably followed the details for the tool and set up a service and a hot key to trigger. I certainly did, and did so a long time before I created the workflow - hence I had no need to replicate that functionality in Alfred. However, I agree that some people may prefer to control it exclusively from Alfred so I'll take a look at adding those options in. Hopefully that covers all of your points.

😵 you are of course absolutely right. I'd completely forgotted I'd figured out how to utilise the alfredpreferences scheme about a year ago 😆

Thanks. I think I've got a workaround based on that. It uses a custom Alfred workflow that can be triggered by the existing scheme, but it sounds like @LucCogZest should be able to build a subscheme for Alfred into Hookmark (née hook) to do this without a need for an Alfred workflow working as a middleman.

Version 1.10.1 now released. No changes to the features, just fixes for some of the diagnostic output to accommodate Drafts and Alfred version changes.

Workflow updated to use user configuration rather than environment variables. Screenshots utilising Alfred default theme.

Workflow updated to use user configuration rather than environment variables. The workflow has some new features, changes, and a new documentation page - https://www.thoughtasylum.com/alfred/alfred_slink_for_searchlink/ Screenshot utilising Alfred default theme. Here's an edited version of the image above that crops it to just the Slink entries for sake of clarity. The workflow also has a new about this workflow. Slink is a helper workflow for Brett Terpstra's *SearchLink* services, a small toolset to help you quickly generate Markdown links. You can download Search Link from its project page on Brett's web site. - https://brettterpstra.com/projects/searchlink/ For details on how to use Slink, read the workflow documentation - https://thoughtasylum.com/alfred/alfred_slink_for_searchlink/ ## Basic Keywords - `sl` - search; results will be copied to the clipboard and based on user configuration, may be inserted. - `slc` - search, placing the results on the clipboard. - `sli` - search, placing the results on the clipboard, and pasting them to the current cursor position. - `sle` - edit the SearchLink configuration file.

Screenshot utilising Alfred default theme.

☹️ I've fixed the link on the theme. There was a stray space in the filename. --- Workflow updated to use user configuration rather than environment variables. Screenshots utilising Alfred default theme.

Workflow updated to use user configuration rather than environment variables. Screenshot utilising Alfred default theme. Slightly revised readme. Bypass is an Alfred workflow for working with Apple's Shortcuts app. Its primary purpose is to allow you to launch your Shortcuts workflows (known as shortcuts) from Alfred, potentially even passing in content to be processed. It also supports a number of other functions to help you work with and trigger shortcuts. Bypass contains a number of keyword, external trigger, snippet and universal action triggers to enable this functionality. ## Documentation - https://thoughtasylum.com/alfred/alfred_bypass_for_shortcuts/

See details in this response on another thread to this. It does not appear to be related to a disabled shadow on screenshots. There looks to be an issue with Alfred and the theme I've been using (forever) - the shadow is omitted when the screenshot is taken whereas with other themes the shadow is included. As noted there, I propose to do the screenshots using the default "Alfred" theme.

My point is not to make it too easy to break or misconfigure. This is an example where in user configuration, if there was an "Advanced" section, it would be under there - things you shouldn't need to tinker with, but if you know exactly what you are doing, you can. As it is, with user configuration, everything is presented nicely and encourages users to change things. My pre-user configuration solution was to build the "basic" settings in as things that the workflow itsefl could set and change, and the "advanced" settings could only be changed by going into the environment variables and manually setting them. I try to provide a good level of suport for folks using the workflows I've created, and from many years in IT development and support roles I know that having options available is really useful, but if things are handed to people openly, there are some who will change things and swear blind they never touched anything and you spend a lot of time tracking those down as through lying or honest forgetfulness, the end user leads you on a circuitous route to tracking down the underlying issue.

A reboot didn't help (I did try that a day or do after), and yesterday I updated to Ventura and the missing shadow persists, which suggests to me it is tied to some property of my theme. I've been using it since maybe v1 or v2 - it's been so long and I haven't wanted to change it or have any issues with it until now. It can be downloaded here. The blur is set as "No Blur", not the deprecated classic blur. I've had a quick scan through the JSON that seems to specify the format, and I don't see any obviously spurious values. I duplicated the Alfred theme, reordered a few sections to aklign them and did a side-by-side comparison. The only structural difference looks to be the inclusion of the credit attribute. In terms of moving to using user configuration over environment variables, I'm going to switch things over. I've done some preliminary testing (and I think longer term I'll switch to the simpler AppleScript code, but the JavaScript I have in place does appear to work) and it seems to be working okay on a test workflow I've created, but I'll need to ensure I'm doing more thorough testing on the existing workflows - I don't want to inadvertently break something and miss it through lack of testing. I'll update the posts on the forum with the screenshots and note updates to use user configuration as I apply them.

Hmmm, I guess I mights have disabled it some time in the dim and distant past. I don't use the macOS screenshot functionality and I haven't done so for a very long time. I've used a few different apps over the years - ones that have given me more options for multiple saves and annotations. That being said, if I run the terminal command to force enablement and screenshot my terminal, I get a shadow Whereas, with this setting still in place, if I pop my Alfred window up alongside it and use the exact same keyboard commands, I get Alfred with no shadow I can see Though if I paste the image into an image editor, or highlight it here as I'm editing, it does have the space around it to hold the shadow. I wondered if my theme was messing things up, so I thought I'd try changing it. If I change to the default theme I get ... a third(?)... of a shadow? If I restart Alfred, I get a full shadow. But then if I change back to my previous theme, I get no shadow again. Any known issues with themes (I'm on 5.0.4 FWIW) affecting screenshot shadows? 🤔 Its late and I need to get to bed so I'll tackle the screenshots tomorrow - probably with an alternate shadowable theme. I would suggest that with the contrinued existence rather than migration of the variables and how the documentation describes it, that it could be clearer. I think "vastly clearer for users" and "kmdelay, which I’ve had to recheck several times while replying" are a point for new users. I'm not discounting it asa positive point, but it isn't globally applicable. For example, keywords to set values is much faster to do (and ingrained for existing users) than accessing the user configuration. That's like keyboard shortcuts and menus - but most Alfred users are keyboard nerds right? 😁 The "documentation included in context" is a double edged sword. I suspect usually it is a good thing, but there are times when you need to walk people through a variable in more detail (I realise you can add the details, but it feels like it'll become off putting for someone new if there's too much info). So, not a universal plus, but certainly more pro than con and there are ways to deal with providing such documentation (e.g. "DO NOT CHANGE THIS ... unless you read the manual first, in which case go ahead" 😉). This one I think is something I haven't really thought through to date. I'd already solved the problems I needed to so I probably haven't really thought deeply about it from this angle. But simpler is better, and that's something that now I've started considering it is the single most persuasive point for me. I'll sleep on it (and probably come to the conclusion it is worth a change) and figure out next step, timelines for doing it (updating docs, etc.) for this and the other workflows.