[masklinn]

> While searching for things in the immediately loaded buffer is easy (CTRL+F), searching for things said a long time ago can't be searched via the client. You either have to use command line tools to dump the sqlite db into a grepable text file or install the quasselsuche web app (last updated in 2012).

Why not just open the sqlite file and search in there? Could even ask for the log to be stored in an FTS table for fast FTS queries.

[jbermudes]

That may work, but then you're in the same workflow as the more traditional IRC clients with their .txt logfiles and needing tools external to the IRC client. Ostensibly the point of moving away from the human-readable logfiles to something like an SQL DB was to let the client be a more powerful search engine into your chat history. So this is mostly a lament that while there's a great vision to what an IRC client can be in designing Quassel's infrastructure, Quassel has not yet fully realized its vision in this area, but I'm sure it'll get there some day.

[rhizome]

but then you're in the same workflow as the more traditional IRC clients with their .txt logfiles and needing tools external to the IRC client

Is this really a problem?

[aseipp]

I think the OP's original complaint is bore out of the idea that: if the client is already storing the logs in a structured format with a schema to accompany it, and the data engine has query features for that data which is powerful like grep (as SQL does), and it's already using that engine to power search for the immediate buffer - it seems a bit odd then to not build 'global' search right into the application, for all logs, based on the same mechanism.

I think it's nice you can do all the SQL dumping/munging stuff, given the implementation. I just don't want that in 99% of all use cases - the application doing search itself is enough normally. It's not like I use any of grep's more powerful features when I search logs, 99% of the time it's just something like "| grep foo" and I narrow it down iteratively or just pick out the result.

Honestly, technical specifics aside, this is also a matter of usability, and is something Slack gets very right: you never have to do anything for search to work well for the vast majority of use cases, even for very long histories. You just type the words you want and the results always come back, even from weeks or months before. Telling users to enable logs and then search text files is just much more activation energy. Telling them to do that after exporting their data from SQLite, even more so.