feature request for the search box:
- add logical operators AND (+), OR (|), NOT (-)
- add filters like filename:, path:, content:, title:, type:, size:,…
Not sure where the 
is on this post, but I +1 this!
Could this be done using existing queries? I need to take another look at how queries work, as they seem quite powerful, but not yet super “easy to use” for less technically save people.
1 Like
@mosch search and queries have different use-cases in my opinion : search is used for quick lookup (think temporary/fleeting) while queries act as dynamic blocks : their use is more permanent, you keep the block with the queries, but its content will evolve over time.
so no, even if you could use queries to retrieve the same result as a search, queries are not a suitable replacement for the search box feature.
the search-box has full-text search whereas the queries use the predefined datascript schema.
4 Likes
I agree and at the same time I would not exclude cross-usage.
Once you reach a certain number of pages or files in general (eg. a lot of files with the same word in the file name) full text search is reaching it’s limit and having additional ways to scope the search (eg. date: last year) can become helpful.
full text search is reaching it’s limit and having additional ways to scope the search (eg. date: last year) can become helpful
which is exactly why this feature request exists. Filters and operators can help to scope a search.
using advanced query as a workaround may pull the same results but in terms of ux, this is not a suitable subsitute to an advanced search box.
2 Likes
Any updates or ETA for this feature? This is a critical missing feature IMO, especially as you begin to have lots of pages in your graph.
Most of the times I just want to search for page names (vs searches of mentions across pages). Right now, there is no way to do that, and doing a search for anything other than exact page names shows too many results. What makes it harder to navigate is that page names are often not even near the top of search results, which makes it very hard to quickly switch across multiple pages through quick searches.
4 Likes
Similarly, it would be nice to be able to use wildcards or regex on in-note filters used to filter linked references.
1 Like
I would argue against query not being suitable for search.
If you have rich database with a lot of data and metadata, you have to have a flexible and rich way to retrieve what you need (to query it…).
Look at Jira. To search issues, you can use JQL (Jira Query Language). If you want to collect issues and present in a form of table, chart - to fetch proper set of issues you use JQL statement. Temporal search and persistent reports have the same input.
So yes, I would like to open a search box and type in a query. Usually my information need is formed as a query in my head: “pending tasks for this project”, “profilers i used when coding python”. You can express this in today’s query.
But… That’s not what I would like to use every day. Neither for search box, nor for the table/list generation.
What makes more sense for me (from usage point of view, not an enormous effort it may take to implement) is a human readable and more natural language query language. Easy to use to search. Easy to use to prepare data set for table.
I’m puzzled on how people browse through so many filters results. Do they build queries all the time? That’s not productive at all. Really need this feature 
Not that I disagree with better search (and I’m a sucker for BOOLEAN searches, so +1), but yeah, I create simple searches all the time, just to get an overview of things.
But anytime I’m deliberately looking for something in a specific context, iand it’s not linked or back-linked I update my links. Everything important should be findable through linking.
Search should really be a last resort, in a well-organized PKM. (The last resort should still work well, so I still vote +1, but you get the idea 
)
I get it. I’m constantly going to pages and lookin for specific filters that I already know. For instance, I go to a Project Page, and I want to know a subject of a specific requirement (also a page), well you would agree with me that I’m a two clicks away of my result. Now, with queries, it forces me to spend energy thinking on the statement condition. Man, I already write enough code in my day hahahaha 
I think a basic search on the filter result, such as roam is more than enough 
1 Like
I like the suggested reuse of advanced queries. Datalog is already powerful enough to do almost anything (I haven’t fully learned it but I will!) and the custom implementation of queries allows fillable inputs. Plus queries are named. If you add one more property to queries, something like extend-search: true then the flagged queries could be selected by name and their inputs supplied.
Reusing queries overcomes the need to evolve the search box syntax. One could even extend basics queries a bit to make them work the same way.
I would also love the ability to search within the filter. My current setup is to use tags instead of actual pages to organize my notes within a parent-child relationship, which has resulted in a lot of tags within the filter. It’s amazingly useful, but being able to filter the tags by searching would make it even more awesome!
1 Like
I strongly disagree with the idea that adv queries are a suitable replacement for a good search box, they complement each other:
- in terms of ui, a search box enables quick lookup :
type - > get instant results - > refine/filter/sort - > get updated results
the key idea is getting immediate results without having to put too much thought (eventually find-as-you-type, real-time update of results), as opposed to thinking beforehand of your results requirements and thinking about a complex syntax - this relates to the idea of wanting a permanent (results of queries that will update overtime and you need to come back to) or a fleeting list of results (you just need a quick lookup via a modal, you don’t need to keep the results for later, and don’t want to write a query just to erase it once you get your results)
- a powerful search module could be used in multiple aspects of logseq :
- main search box
- filters for linked ref (where a search box is a must have)
- plugins/marketplace advanced search (as the number of plugins grow it will be handy to search and filter available plugins using operators and filters, author:xxx AND modified-date:yesterday)… I don’t want to write a complex query for that, I need a powerful search box
- searching the help section, etc…
so, under the hood, it may use adv queries or not, but the paradigm of a good search box covers use-cases that are not achieved with queries.
this is not only about getting a relevant list of results, this is about how you get that list of results ui/ux wise
4 Likes
The SmartSearch plugin from sethyuan is very good. it adds filtering by tags, properties, dates, etc… and some operators (not)… but it only works in edit mode (for now ?).
I hope the native search can leverage some of this.
2 Likes