Conditional `hide task count`

[ilandikov]

⚠️ Please check that this feature request hasn't been suggested before.

• [X] I searched previous Ideas in Discussions didn't find any similar feature requests.
• [X] I searched previous Issues didn't find any similar feature requests.
• [X] I am only requesting a single feature. Multiple changes should be split into individual requests, with links between them.
• [X] I believe my requested feature will be generally applicable to other users, not just me: it is not uniquely tied to my personal workflow.

🔖 Feature description

I often use the hide task count instruction to remove the useless information and shorten the Tasks output.

However if no tasks are found with the request the 0 tasks output is quite helpful instead of just -nothing-.

✔️ Solution

I would like to have an option to hide the tasks count only if tasks were found, for example:

• hide non-zero task count - hide if task count > 0
  • simple
  • not universal, works for only my use-case
• hide task count >0 - implement a mechanism similar to filter by function where the >0 is interpreted as taskCount >0
  • harder to implement
  • more flexible

Please note these are vague examples, I'm open to any suggestions on how to word this instruction.

❓ Alternatives

No response

📝 Additional Context

No response

[claremacrae]

Hi @ilandikov, thanks for the suggestion.

I think this would be useful. There have been various other suggestions to improve the limiting option, like indicating if the limit was exceeded at the bottom of the search.

On the implementation, the existing limit code has already been getting more complex, and there is probably somewhat duplicated logic in the parsing, limiting and explain code between limit 5 and limit groups 5.

Basically, both the limit facilities may be considered small examples of 'primitive obsession' - storing numbers instead of behaviour.

I have some ideas about how to improve this, and had thought I might refactor it after the limit groups feature was merged, but there has been too much other stuff going on, Tasks-wise.

I'd be happy to use one of our pairing sessions to start exploring this refactoring and where it might go...

[ilandikov]

I honestly don’t see the relationship with the limiting but yeah let’s explore that together =)

[claremacrae]

I honestly don’t see the relationship with the limiting but yeah let’s explore that together =)

Fair. Yeah, there's too much in my head to put everything down here...

[claremacrae]

I honestly don’t see the relationship with the limiting but yeah let’s explore that together =)

So, another comment that may be more obviously related:

There also needs to be an abstraction for the show/hide commands, both to reduce the amount of edits needed when adding new ones, and to enable them to be mentioned in explain output.

Am also happy to pair on this!

[ilandikov]

There also needs to be an abstraction for the show/hide commands, both to reduce the amount of edits needed when adding new ones, and to enable them to be mentioned in explain output.

oh yes! I had the same thought and ttried to refactor it by myself but didn't get anywhere

[claremacrae]

See also #2380.