Jump to content

Adding shortcut to iterate over recent alfred commands not only back but and forth


40-02

Recommended Posts

Hey Guys!:) 
Could you, please, consider adding the shortcut to cycle through the history of alfred commands forth. 
I understand that there is only 20 commands in history, but still - I often find myself cycling through them and skipping occasionally the needed result for me, so I have to start for my search once again from the beginning. 

 

I'm talking about addition to this feature: 

https://www.alfredapp.com/blog/tips-and-tricks/quick-tip-view-your-recent-query-history/

Edited by 40-02
Link to comment
Share on other sites

  • 4 weeks later...

I also bump into this from time to time. It makes me press ↑ very slowly, and even then I sometimes make a mistake. We can’t simply use ↓ for the next command, which is understandable, but maybe something like ⌃↓ (ctrl + down) would be acceptable.

 

Alternatively, I’d like to do something possibly even better: use a Script Filter to show all recent commands (without running them) and let us select the one we want in context. @Andrew is there a way for us to grab that history, even if unofficially (like we can read the clipboard DB directly, for example)? On first glance there doesn’t seem to be, but thought I’d ask anyway.

Link to comment
Share on other sites

1 hour ago, vitor said:

is there a way for us to grab that history, even if unofficially

 

I'm certain it's in-memory only. Goes away when you restart Alfred.

 

I'd love to see a larger, searchable history. I'd like to be able to easily go back to previous searches in Alfred the way I can in my browser.

Link to comment
Share on other sites

11 hours ago, Mr Pennyworth said:

It's rough around the edges, but better than nothing

 

I disagree. We’ve already established that I find your recent solutions ingenious and interesting, but this one doesn’t make the cut for me.

 

Alfred is designed to be called explicitly (which I think is the right call) and I’m not at all a fan of solutions that try to circumvent that by adding a script filter to every letter. If people keep building these, soon we’ll have several Workflows competing with several other, which isn’t a sustainable solution.

Link to comment
Share on other sites

6 hours ago, vitor said:

We’ve already established that I find your recent solutions ingenious and interesting

Gee, thanks! ☺️

 

6 hours ago, vitor said:

but this one doesn’t make the cut for me.

Yep, very much understandable! :)

 

6 hours ago, vitor said:

Alfred is designed to be called explicitly (which I think is the right call) and I’m not at all a fan of solutions that try to circumvent that by adding a script filter to every letter.

Valid points!
In fact, the points you made are a short and condensed version of all the "caveats and disclaimers" I explained here:

 

I think we differ in our core philosophies, your arguments make me believe you might be more of the "MIT philosophy" guy while I find "worse is better" more appealing (https://www.jwz.org/doc/worse-is-better.html). Furthermore, if there's something I really really want, and I have no control over "the correct way of doing it", I would rather go ahead and put together some ugly hacks till I make it work than wait for the official, correct way to materialize.

 

Quote

Alfred is designed to be called explicitly

Disagree.
It already mixes

  • file searches
  • contact searches
  • web bookmarks
  • calculator

I would agree that Aalfred's treatment of built-in features differs from the treatment of third-party workflows.
I would agree to a modified version of the statement for sure though: "Alfred's workflows are designed to be called explicitly"
And even that, I wouldn't bet my money on. Because I don't know what goes on / went on in @Andrew's brain. Did he design it like that? Did it just happen to end up being like that? I would guess, but wouldn't claim to know.

 

6 hours ago, vitor said:

I’m not at all a fan of solutions that try to circumvent that by adding a script filter to every letter. If people keep building these, soon we’ll have several Workflows competing with several other, which isn’t a sustainable solution.

I'm not at all a fan of slippery-slope statements and unjustified generalizations.
They add words to a discussion without adding any substance.

  1. The generalization isn't justified because most workflows are meant to do something specific, and not something universal. When a workflow (like this one) is meant to do something "alfred-wide" and/or "meta", it doesn't make sense to me to discuss "what if many workflows...". The answer to "what if many workflows ...?" question is a simple one: "why would many workflows ...?".
  2. If people keep building these
    1. If a whole lot of people do not build such workflows, or if no one really wants to use them, the sustainability problem never arises.
    2. If a whole lot of people do that and a whole lot of uses start using those and it becomes a performance problem, that's such a great signal for @Andrew that there's a super-popular way people are using Alfred that he initially hadn't designed for. If it were a product that I developed and I come across such a thing, I would be thrilled to discover something like this. The best feedback a developer could get is users voting with their usage patterns than a few vocal people requesting on a forum.
  3. Several workflows competing with each other
    1. Scenario: The competing workflows make the default results not very usable or unpredictable. (doesn't apply here anyway)
      Result: People disable / uninstall such workflows.
      Looks to me like a problem that solves itself.
    2. I don't see why this point is relevant at all to this particular discussion
      1. The history logger doesn't compete with anything, as it produces 0 results
      2. It is not a significant performance hog as barring in-memory operations, appending at the end of a file is one of the cheapest operations there is.
  4. "Script filter for every letter"
    That makes it sound like that's particularly expensive. I'm sure beneath Alfred, there is solid design and sound data structures (a trie that stores the keywords comes to mind). Even though there are more than 40 script filters in the workflow, at any given instant, it is practically equivalent to one script filter. (User types the first letter -> Alfred picks 1 among the 40: that would ideally be a constant-time operation, and a fast one at that. After the first letter, for the subsequent letters, assuming a trie-like implementation, there should be zero overhead in picking (as it already has been picked) the filter). The complaint about "one script filter for every letter" is similar to complaining about the number of entries in a hash table. The whole point of a hash table is that the size doesn't really matter, the lookups take constant time.
    I'm just making this point because any non-programmer person reading your comment would get the impression that "having so many script filters is scary/heavy". I'd guess that you didn't want to create that impression either. I'm just saying that it could come across as that. So, I'm clarifying here that the number of script filters here is almost immaterial, especially if all of them are mutually exclusive.

My summery technical characterization:

  • It is one extra script filter
    • that runs asynchronously (like every other)
    • that doesn't interfere with results
    • that doesn't delay the results
    • that is computationally damn cheap
Link to comment
Share on other sites

3 hours ago, Mr Pennyworth said:

Did he design it like that? Did it just happen to end up being like that?

 

I'm sure it was a deliberate decision to not allow user-written code to run without being explicitly called by the user. Performance is a super-high priority, and allowing arbitrary workflows to run whenever Alfred is opened isn't really compatible with that.

 

3 hours ago, Mr Pennyworth said:

I'm not at all a fan of slippery-slope statements and unjustified generalizations.

 

Me, neither, but that's the way it will go down if this Script Filter trick catches on.

 

Neither workflow developers nor users will show any restraint in building or installing such workflows because the former always think their own programs are special cases, and the latter tend not to think about such things at all.

 

I doubt we'll see official support going very far in this direction because it doesn't pass the "no footguns" test.

Edited by deanishe
Link to comment
Share on other sites

Right, for the next 4.3 pre-release, I've added ⌃↑ and ⌃↓ to navigate the history in the default results at any point (even if you have typed a different query).

 

These shortcuts by default are used in macOS for Mission Control, and Application Windows, so these associations will need to be disabled in the macOS Mission Control prefs for these shortcuts to work within Alfred.

 

I should nave the next pre-release out some time this week.

Link to comment
Share on other sites

@Mr Pennyworth Just to make sure we keep discussing on the right foot, I’ll preemptively say—because we haven’t interacted much yet—I believe we’re both arguing in good faith and I intend to keep it that way.

 

8 hours ago, Mr Pennyworth said:

I think we differ in our core philosophies, your arguments make me believe you might be more of the "MIT philosophy" guy while I find "worse is better" more appealing (https://www.jwz.org/doc/worse-is-better.html).

 

If you send me a link defending the former, I can compare and decide.

 

8 hours ago, Mr Pennyworth said:

I would rather go ahead and put together some ugly hacks till I make it work than wait for the official, correct way to materialize.

 

Like making a Script Filter self-update, or a single-player or multi-player Alfred game.


I understand the tradeoff of ugly hacks; it is my opinion the tradeoffs for this one overshadow the gains. Like I said, this one doesn’t cut it for me.

 

 

8 hours ago, Mr Pennyworth said:

I'm not at all a fan of slippery-slope statements and unjustified generalizations.
They add words to a discussion without adding any substance.

 

On the contrary, I see that as fallacy fallacy.


I’m not sure how (but I’ll take a suggestion) I could’ve made my point another way; we’re talking about something that hasn’t had the time to be proven either way yet. It’s like Portugal’s drug policy: one side claimed it would lead to widespread rehabilitation and the other to widespread increased consumption. The former was right, but both could have been called slippery slopes. And the whole goal of the policy was the slope (for the better).


But back to the point, I’m perfectly justified in making that assumption, because I read almost every post on this forum and I’ve seen a request for this popup more than once. So in answer to your question:

 

8 hours ago, Mr Pennyworth said:

question is a simple one: "why would many workflows ...?".

 

Because they can. Read the feature requests for a while and you’ll see several that aren’t feasible or reasonable, because not everyone thinks about or understands the full implications of their ask. Which is fine; Alfred’s userbase contains plenty of non-technical users and not everyone has to know that deep down computers suck and everything is held by duct tape (to the surprise of no one, there’s an XKCD for that).

 

8 hours ago, Mr Pennyworth said:

Result: People disable / uninstall such workflows.
Looks to me like a problem that solves itself.

 

I think you’re overestimating the technical proficiency of the average user. What’s likely is that person will not understand which Workflow is causing the issue and think it’s Alfred. As above, to see that one need only read the forum questions (and once more, it’s fine that people who don’t care for technical matters to not understand the cause).

 

8 hours ago, Mr Pennyworth said:

I'm just making this point because any non-programmer person reading your comment would get the impression that "having so many script filters is scary/heavy". I'd guess that you didn't want to create that impression either.

(…)

My summery technical characterization

 

Right. Again, I’m a fan of your ingenious solutions and I’m confident you think about the implications of your work and are perfectly capable of deciding on acceptable tradeoffs. But as someone who cares enough for Alfred to read almost every forum post and spend the time to build Workflows I’ll never use, I try to think of every development as “how will this affect the community and experience as a whole”, because that has a major impact on Alfred’s future.


To end, I’ll reiterate I think you and your solutions are a welcome addition to the community and I hope we can keep arguing based on the technical merits of solutions.

Link to comment
Share on other sites

3 hours ago, Andrew said:

Right, for the next 4.3 pre-release, I've added ⌃↑ and ⌃↓ to navigate the history in the default results at any point (even if you have typed a different query).

 

These shortcuts by default are used in macOS for Mission Control, and Application Windows, so these associations will need to be disabled in the macOS Mission Control prefs for these shortcuts to work within Alfred.

 

I though those shortcuts where already in use before suggesting it, but when I tried nothing happened. Looks like I had already disabled them.


Maybe ⌘ or ⌥ would be a better choice1, now that I take another look, because those can be triggered one-handed. It’s not a big deal for me, but it might be for someone else.

 


1. I don’t mention ⇧ because with the arrow keys that’s a text selection shortcut. Plus, ⇧↑ on the same side is an awkward finger position.
Link to comment
Share on other sites

16 minutes ago, vitor said:

Maybe ⌘ or ⌥ would be a better choice

 

Cmd + arrows navigates in and out of File Navigation, and Alt + arrows is used for the File Buffer, so those combos are very much in use already in Alfred. 

 

It's not just a case of what's comfortable, but also what's practical without affecting existing hotkeys and habits, so quite a bit of consideration and thought has gone into this. :) 

Link to comment
Share on other sites

1 hour ago, vitor said:

@Mr Pennyworth Just to make sure we keep discussing on the right foot, I’ll preemptively say—because we haven’t interacted much yet—I believe we’re both arguing in good faith and I intend to keep it that way.

@vitor

Absolutely! ☺️

 

1 hour ago, vitor said:

If you send me a link defending the former, I can compare and decide.

Isn't the former what most programmers strive to do?
Rigorous considerations of memory usage, cpu usage, disk IO, network latency etc, and meticulous design considerations.
So I thought it doesn't need defending. Be as it may, I stand corrected. Looking at all the examples you posted, you're definitely not averse to quick-and-dirty hacking and tinkering :)
The conclusion that I drew that it is a core MIT-vs-Berkeley philosophical difference seems to have been wrong!
More like it was based my own lack of foresight and all-round understanding of Alfred, and the community.

 

1 hour ago, vitor said:

I’m perfectly justified in making that assumption, because I read almost every post on this forum and I’ve seen a request for this popup more than once.

I see that now, and completely agree!

 

10 hours ago, Mr Pennyworth said:
  1. Scenario: The competing workflows make the default results not very usable or unpredictable. (doesn't apply here anyway)
  2. Result: People disable / uninstall such workflows.
  3. Looks to me like a problem that solves itself.

I also realize the core of my argument is likely completely wrong. I had a sample size of one. "What would I, as a user do, if workflows started slowing Alfred down?". In addition, you have years of experience, and a sample size of users at least three orders of magnitude bigger.

 

I really appreciate the patience, and the detailed and explanatory nature of your answer!
(And @deanishe and @Andrew's answers)

So many considerations and tradeoffs I hadn't even bothered to think about!

You all are the best! 🍻

Edited by Mr Pennyworth
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...