Proposal: Search by type

[chocopowwwa]

I know there have been some issues requesting this feature (https://github.com/zealdocs/zeal/issues/795 for example), I also aware that the that some docset also have different DB structure (C++ and rust for example) and the type column has no standard, anyway

I'd like to offer a proposal to solve this issue,

• In the #795 issue you mentioned about https://github.com/zealdocs/zeal/blob/c6003e19b93cf45ba96d06b2e7b68efe88c501a3/src/libs/registry/docset.cpp#L528-L651, and yeah I think it's a pain to map all the keyword from db to your code, so my proposal is to use the keyword as is, to help zeal user discover what are the correct types in particular Docset, I propose another list view below the search box, so there would be three sections in it, whenever Zeal user click the item on that list it add the chosen list to the Zeal query
• Syntax: Current zeal query format is LANG[,LANG][:]search, with the search by type functionality the query is LANG[,LANG][:]search[@TYPE[,TYPE]] with @ symbol as a separator between search and type

[gerardlt]

I just found myself wanting to narrow by type, so can I add a "me too" on this proposal. :slightly_smiling_face:

I've also got a suggestion you might want to consider. I looked at the linked issues, and while I agreed with the decision not to merge #1038 without considering the design, I'd like to suggest combining the syntax from that proposal with the one proposed here. Namely, to use a prefix like #1038 suggested, but only if preceded by an @ symbol.

For example, to search for the guide on range-based for loops in C++, the search string might end up as: @d:cpp range @t:guide

I'd expect multiple uses of the same prefix to give the union of the specified items, so that: @d:android @d:java @t:class point @t:function @t:method would list all the methods, functions and classes from both the android and java docsets matching the "point" search string.

The main advantage of a prefix is that it keeps the door open to add other criteria, meaning the current constraint on syntax changes would be easier to cope with in future.

The suggestion makes at least two assumptions I could readily identify:

1. that @ isn't typically used in search strings. I say typically because if needed, it could be escaped. But I assume this isn't a problem based on it's use in the existing proposal.
2. that spaces wouldn't typically be needed to identify document types or docsets. If needed, quoting would be preferable here.

Note the second assumption would also apply to any future extension of the criteria.

I think for backwards compatibility the existing syntax could continue to be supported, so that this would be equivalent to the search suggested above: cpp: @t:guide range. Note that supporting this would add a third assumption:

3. no docset ids begin with an @ symbol. (There might be some hacky options for working around that if needed.)