It’s a great macro, but it is intolerably slow in operation for me.
Then you must have a very slow Mac. I've been using it for a couple of years now, and it always has been fast for me, using any of these Macs:
- 2013 MBP Intel Core i7 (2.7GHz)
- 2015 iMac-27 Quad Core 3.3 GHz Intel "Core i5"
- 2019 iMac-27 3.6GHz 8-core Intel Core i9
That might be true for you, but it's not true that the only explanation is that my Mac is slow. None of my Macs is slow. Also, the slowness of the macro has been mentioned by others on this forum.
For you, and any others that find Dan's Spotlight Search slow, it must be due to conditions on your Mac. I just tested it again with his macro that allows you to select a macro, and even with my 2300+ macros, it was near instantaneous. I guess we'll just have to agree to disagree about the performance of this macro.
It works well for simple lists. But I need to use it for a list that’s hundreds of entries long, and each entry is hundreds or thousands of characters long. This bogs down the search functionality of the macro. So it’s not necessarily a machine issue; it’s more likely that it’s a use-case issue. I made my own HTML-prompt macro that works lightning fast, which is proof that it’s not a machine issue. The only drawback of mine is that it doesn’t have standard arrow-key navigation, but I found a way around that, as well.
No joke! ==That is an extreme and rare use-case==. I don't think it is fair to @DanThomas for you to state his macro is slow when you are trying to use it for such a rare use case. I can't image the need or benefit of having each line be thousands of characters long.
I agree that it's an extraordinary use-case. That's why I wrote that the macro is intolerably slow for me. I'm not sure why you're interpreting this as an attack on Dan. I stated that his macro is great. But it is not my opinion that it is slower than other list-searching macros (including KM's Prompt With List, which processes my extraordinarily complex list instantaneously); rather it is a fact that Dan's is slower. For the vast majority of people, that might make no practical difference. For example if Macro A performs Job X in 100 milliseconds, and Macro B performs Job X in 1 millisecond, then either macro, in practice, will be acceptable. However, Macro A is still 100 times slower than Macro B in that example. If Job Y (much more demanding than Job X) must be performed, and the difference is that Macro B takes 0.5 second, and Macro A takes 50 seconds , then it becomes a practical problem.
You clearly, IMO, left the impression that Dan's macro was slow.
While you did say " intolerably slow for me", it is NOT clear that is because of your extreme, rare, use-case. Given your rare use-case, I see no point in your post in this thread.
IAC, we have gone off-topic, so I'm moving our discussion to a new topic.
It's not an impression that Dan's macro is comparatively slow; it's a fact. Anyone carefully reading my previous post can understand that the comparative slowness just doesn't matter for most people, and that is fine for those people for which it doesn't matter (including you). But pretending (and writing) that it is not slower (presumably because you don't want it to be true that it's slower) is misleading to others.
As a general statement, that is incorrect. It is only your use case that is slow.
You are wrong, and for the same reason again. "Comparatively slow" means "slow compared to some other thing". It does not mean "so slow that you’ll notice" or "so slow that you’ll risk hurting Dan’s feelings". Compared to KM’s built-in Prompt With List (or the HTML prompt that I use), Dan’s macro is slower, whether the searched list is simple, or whether the searched list is so complex that the user will notice the comparative slowness. That fact is unaltered by your unwillingness to accept it.
I'll not debate this with you any further.
To All Other Readers
Based on actual experience, I just want you to know that for the very large majority of use cases, the MACRO: Spotlight Search Prompt by @DanThomas. is NOT slow when run on a modern Mac. I feel sure you will be happy with both its features and performance.
@thoffman666 Just so you guys know, I'm not insulted if someone says it's slow. It is what it is. If it works for you, great. If not, oh well. At least I don't have to refund anyone's money. 
1 Like
That's exactly what I suspected you would say, Dan. As I said in my original post (which somehow offended @JMichaelTX), your macro is great, despite the fact that it bogs down under high search load. In fact, the greatness of your macro is exactly why I wish I could use it. I originally (long ago) looked to your macro to solve KM's problem of not having sufficiently wide (or user configurable) Prompt With List boxes. In fact, the inability to make a Prompt With List box span the width of the screen was my biggest complaint about KM 8, and so my greatest hope for KM 9 was that full width would be available. It was the very first thing I checked when I purchased KM 9. Alas, that feature request was not granted. I truly hope that a future release will include it.
Thanks for that. And if you know any web development, or know someone who does, maybe they can make a custom HTML prompt with better performance. I barely know what I'm doing most of the time, so I'm sure someone with more web experience could solve the issue. Mind you, I'm not downplaying what I've done, but I'm also very aware of my limitations. 
Well, that's exactly what I ended up doing. So I have an HTML-based prompt that now searches quickly, but I can't figure out how to implement arrow-key navigation. I ended up using KM actions (after invocation of the HTML prompt) to mimic arrow-key navigation, and it works well enough. But I wish I knew how to add it to the HTML to make the navigation work like a KM Promp With List. Anyway, thanks for all of your quality macros.
Inside the PKG file, there's a file named "Spotlight Search Prompt.html". Inside it there's a pseudo-class called "NewSpotlightSearchHandler". It contains all the logic for doing the searching, and also the arrow key handling. At least, if memory serves.
So 1) it might give you some ideas on how to implement the arrow keys, and 2) I stole the search logic from somewhere, so maybe you can improve it? I remember thinking that all I cared was to make it "fast enough" for what I needed. Maybe there's some obvious places for speed improvements.
I'll be happy to answer any questions, assuming I even remember what I was doing. 
Great. I once tried to look in your macro, but I didn’t really know where to find what I was looking for, so thanks for specifically pointing to it. I’ll have a look, and if I make a breakthrough, I’ll certainly let you know. Many thanks.
Great. Everything I've done was built on the back of someone else, so I have no problems with other people messing with what I've done. I mean, what's programming, if not piecing together stuff someone else wrote? 
I'm following through with your request to see what I came up with to overcome the limitations of Prompt With List. Here's a quick and dirty (non-prettified) HTML prompt to illustrate how I quickly search a long list of long entries. The example entries were stripped from the Earth page of Wikipedia. The content is not the point. The point is that the list can be searched very quickly (i.e., without bogging down), and the narrowed results can be navigated with up and down arrows. In practice (for my real list), I use a skeleton HTML prompt that reads the entries from a (growing) file that I keep on Dropbox.
Custom HTML Prompt for Complex List Macro (v9.0.2)
Custom HTML Prompt for Complex List.kmmacros (103 KB)
This uses JQuery, so see https://jqueryui.com/ for options.