Feature Request: A Dedicated 'Hidden' / 'Do Not Search' Group

Questions & Suggestions
1

Wondering if anybody else here might join me in badgering Peter to add a special group to KM which has a single, defining property: that the macros within it are excluded from search results. (Whether or not there are any macros within it at any given time, of course, is up to the user.)

My reasoning/use-case for such a feature is as follows:

I’m one of those easily excitable and easily distractable types who has more macros in KM that are of the in-progress, not-currently-in-use, set-aside-for-the-moment, this-isn’t-quite-working-yet, these-are-the-previous-nine-iterations-but-number-ten-may-prove-to-have-a-bug-so-I-better-keep-the-others-around, and these-are-obviated-but-are-they-really-maybe-they’ll-be-useful-at-some-later-date type than macros that are of the this-is-a-finished, in-play, I’m-actually-using-this-one type.

I think you get the point.

As a result of my disorganization, lack of follow-through, and hoarding tendencies, when using the search feature my results tend to have more noise than signal.

Being more diligent about throwing macros out is always an option, of course, but there are macros for which I seem to desire a middle-ground – a place I can put them where they won’t get in the way, but will be there to dig through if I’m ever feeling nostalgic.

Any one else feel a feature like this would enhance their Keyboard Maestro experience?

2

Maybe it could be a checkbox on a group?
:heavy_check_mark:️Do not search this group

I have some groups for test, temporary and for this forum. And it could be
nice if the did not get searched.
tor. 16. apr. 2015 kl. 06.04 skrev samsam <kmforum@forum.keyboardmaestro.com

3

We hammered Startly Technologies for years to get them to add better search features to QuicKeys, and version 4 finally included a pretty darn comprehensive search.

The bottom line is that search needs to help you find what you’re looking for quickly. If it doesn’t then it fails its raison d’être.

I have a rather large ‘Examples Group’ (ordinarily disabled) that I never want to search unless I’m in that group, so I get where you’re coming from.

NOTE: You can select only those groups you want to search in the editor, although that can be a bit tedious.

Remember that making a strong case is more important than badgering Peter. :wink:

I guess I’d expand the feature request to any and all improvements that can reasonably be made to search.

I suspect Peter has done some of this already, and I know he has his plate pretty full for version 7 already — but by all means throw any good ideas into the pot.

-ccs

4

If I'm hearing you correctly, Chris, you're saying that you recommend hectoring over badgering. Got it. Going forward, hectoring it is.

:slight_smile:

5

I am happy for folks to post suggestions that I am not convinced about (indeed I specifically suggested @samsam post this one). Sometimes it becomes clear that something that I would find no value in would be far more valuable than I anticipate. Sometimes others might simply point out different solutions (either already available, or different ways I might improve Keyboard Maestro to resolve the underlying need). Sometimes nothing might happen except crickets and it becomes clear that its not something that is a widely needed feature.

None of these necessarily predicts my choices, I’ve been known to implement features for a single person and ignore obviously widely desired features in preference to other directions. But all of them provide more information and allow me to make a more informed choice, so I’m happy to see them, and I’m happy for people to plead their case. As @ccstone says, a well reasoned argument is going to be more compelling, and just repeatedly asking for the same thing wont get you a good response (though I’m not opposed to a request being remade annually, sometimes something I didn’t have time for or that didn’t fit previously can get a different response at a later date).

As long as its respectful, and as long as everyone understands that I can only do so much and I have to choose what that “much” is taking in to account a myriad of factors (including my motivation!), then it’s all good and I very much appreciate it.

6

On Wed, Apr 15, 2015 at 8:04 PM, samsam kmforum@forum.keyboardmaestro.com wrote:

a special group to KM which has a single, defining property: that the
macros within it are excluded from search results.

I would use something that achieved the end goal: excluding groups from
search results. My preference would be to have this an option at the group
level: check to exclude this group from search results.

c

Chris Lott chris@chrislott.org

7

Thanks for commenting and clarifying on this thread, Peter – much appreciated.

@Chris_Lott and @JimmyHartlington: Thanks to you also for commenting. If I may speak on Peter’s behalf, he was less-keen on a per-group setting (which was my original suggestion) than on a single do-not-search group (which was my amended suggestion).

If I’m paraphrasing Peter’s thinking accurately, he is loathe to introduce ambiguity, uncertainty, or confusion into the Search functionality. i.e. If the macro exists, Search should find it.

In my view…

Adding a dedicated do-not-search group definitely adds a level of uncertainty – i.e. Search didn’t find the macro I’m looking for, so it’s a) not here, or b) inside the do-not-search group.

But adding a per-group do-not-search state adds additional levels of uncertainty – i.e. Search didn’t find the macro I’m looking for, so it’s a) not here, or b) inside a group set to do-not-search … and if ‘b’ is true then c) which groups do I have set to do-not-search and d) which of these groups is the macro in?

So, if having to choose between the two, I would see the dedicated do-not-search group option as being preferable to the per-group setting option, as it would introduce less uncertainty.

And despite the addition of a bit of uncertainty, I still see the introduction of the feature as being preferable to not having any do-not-search functionality at all. (See original post for ham-fisted attempt at making a case for the feature.)

I could, of course, be wrong – so would love to hear further thoughts on the matter if anyone has any.

Thanks all.

P.S. All of these arguments assume that nested groups and/or visual differentiation for folders set to do-not-search are not on the table.

8

I see value in being able to search subsets of macros, but I’m pretty sure I wouldn’t like a checkbox for ( include/exclude ) from search results. I don’t think I’d like a dedicated unsearchable group either. I’d forget that I checked or unchecked some group, or that it was unsearchable, and frustrate myself while figuring out what’s up. If we were able to define our own smart folders like the ‘All Macros’ smart folder, I think that’d solve most of what’s being suggested here, and there would be no ambiguity around the concept… when you select ‘All macros’ and search, you are searching literally all macros, and in a group, you are searching that group. Perhaps even just a couple more baked-in smart folders would help? Like a smart folder for , ‘All Disabled Macros’, ‘All Enabled Macros’ ? The smart folder/group concept keeps it separate… The groups are there for the macro organization, and the search is search.

Currently though, I’ve just been prepending a ‘z’ in the name of macros I don’t want to use at the moment, but I want to keep around for later, and ‘wip’ in front of stuff that I’m playing with but isn’t ready for real use.

1 Like
9

I think I’d like to see tags supported and searchable.

With a boolean it would then be simple to include or exclude what you want.

Find:

(NOT tag:noFind) name:mail name:reply comment:“Christopher Stone” anytext:“is nuts”

I think I’m probably in favor of the Smart-Groups idea too.

It’d be really handy to be able to tag a macro as ‘Working’ and have it show up in the ‘Working’ Smart-Group.

-ccs

10

On Thu, Apr 23, 2015 at 12:59 PM, samsam kmforum@forum.keyboardmaestro.com wrote:

I would see the dedicated do-not-search group option as being preferable
to the per-group setting option, as it would introduce less uncertainty.

I'm not understanding a) how this setting is any more problematic than any
other per-group settings and b) how it would be better to have to move
macros I want to keep activated and in the proper group based on
function/application to a group that is just for keeping them out of the
search.

The bottom line: I have many macros that I don't want searchable but that I
do want grouped under, say, "Markdown Functions" etc for obvious reasons.
How would having a special group help me?

I agree with ccs's suggestion for tags, though they have their own issues
in terms of ungainliness unless they are fully supported (mass tag editing,
etc).

c

11

HI @Chris_Lott

I'm not understanding a) how this setting is any more problematic than any other per-group settings

Just to clarify, I was not judging a per-group do-not-search setting relative to any other of the per-group settings, but rather relative to my interpretation of Peter's concerns re. potential confusion when Searching. A single location where un-findable items might live seems like it has less potential for confusion than multiple locations where those un-findable items might live. My hope was that the single-location idea might be a workable compromise.

macros I want to keep activated

I have to admit it had never occurred to me that other users would have macros that they want to be both Activated and Un-Searchable. In my use-case, any macros I want un-searchable would also be disabled, so having them live in this dedicated group rather than the group in which they were originally located hadn't seemed like too big a problem to me.

Hi @woof and @ccs and everyone else,

I think I'd like to see tags supported and searchable.

This and the others suggested are all great ideas, to me. Bottom line for me is that my KM experience would be significantly improved if there were a way to prevent some of my in-progress, obviated, or earlier-iteration macros from appearing in the Search results. If Peter were amenable to implementing some way -- any way -- of making this happen, I'd be stoked.

Hope all y'all have a good weekend.

12

On Fri, Apr 24, 2015 at 10:29 AM, samsam kmforum@forum.keyboardmaestro.com wrote:

In my use-case, any macros I want un-searchable would also be disabled

Which opens up another possibility: have an option that deactivated macros,
wherever they might be, are not searched.

c

13

Too true. If Peter ends up wanting to implement something in this area and likes this particular idea the best, the Search function could have three possible user-chosen states:

Search...

  • All
  • Enabled Only
  • Disabled Only

Food for thought. I think.

14

Remember Peter has to support Keyboard Maestro and any general setting that prevents users from being able to find their macros will inevitably lead to many screams of “I can’t find my macros!”

So. Suggestions he implements generally need to create the fewest possible headaches for him.

QuicKeys 4 not only had a filter field, it had a full-fledged search UI.

It was in general development (with gaps) for about 25 years, and many of us had hundreds or thousands of macros in it. Therefore a more powerful FIND became ever more necessary.

I only have 411 macros in Keyboard Maestro right now, but that’s because I run 350+ AppleScripts from FastScripts - and that doesn’t include AppleScripts for apps with their own dedicated script menu.

So. I’m up past 1000 macros and scripts, and this number will continue to grow.

(I would have many more if I hadn’t lost many years of work to a burglary some years back.)

Macro management becomes ever more important. (Pun intended.)

-Chris

15

I know it’s a little after-the-fact to reply to this, but Chris (ccstone), that is an impressive number of scripts and macros. You must have some excellent organizational skills (never mind scripting skills).

And FWIW, please know that I definitely don’t want Peter to have any unnecessary headaches. Just the right amount of headaches for all, I always say.

Speaking of always: thanks – as always – for your valuable input, sir.

1 Like