Merge lp://staging/~koschmieder/zim/zim into lp://staging/~jaap.karssenberg/zim/pyzim

Hi Lukas,

I'm very sorry, but I'm afraid I cannot accept this functionality in it's current form. The big problem I see is that you implement your own search method, rather than re-using the search module and the logic from the dialog. Specifically you load all pages in memory and then search on that - this will break when you have a large notebook on a small computer. The search module in zim uses the cached index and greps through pages one by one (the speed of the grep is still to be improved - I'm planning for that).

My suggestion would be that you make a new version where you re-use the widgets from the search dialog and embed these in the pane. This is trivial. Then you make any improvements for the interface on those widgets, such that both the dialog and the embedded pane benefit.

Regards,

Jaap

Hi Jaap,

thank you for your quick response.

I would also prefer to re-use the search module but I fear that it doesn't meet my requirements.

These are my main concerns:

First, I rate/weight search results by certain criteria and don't see how I could fit my rating system into your search logic.

Second, the key feature of my plug-in is that it shows search results as you type. Judging by how long the default search dialog takes to process a query, I suspect that the underlying logic is too slow/bloated for my needs.

Please let me know what you think. I will try to re-write my plug-in, if you're positive that my concerns are unjustified.

Regards,

Lukas

Hi Lukas,

With respect to the rating system, I'm open to improvements. Just specify
in more detail what you think should be different in the rating and we can
have a look at it. My objective is putting most relevant results on the
top, but I didn't optimize it much.

Search-as-you type for content search will indeed not work in the current
module. But loading the whole notebook in memory to solve that is not the
right way to go. You should either research using the SQLite database as a
search engine to achieve that, or think of optimizations like using
search-as-you-type for cached content like page names and searc hby word
for content. That could certainly work.

Have you looked at the search language we use? If you use keywords for
searches, searching names will be really fast.

Regards,

Jaap

On Sat, May 2, 2015 at 12:05 AM, Lukas M. Koschmieder <email address hidden>
wrote:

> Hi Jaap,
>
> thank you for your quick response.
>
> I would also prefer to re-use the search module but I fear that it doesn't
> meet my requirements.
>
> These are my main concerns:
>
> First, I rate/weight search results by certain criteria and don't see how
> I could fit my rating system into your search logic.
>
> Second, the key feature of my plug-in is that it shows search results as
> you type. Judging by how long the default search dialog takes to process a
> query, I suspect that the underlying logic is too slow/bloated for my needs.
>
> Please let me know what you think. I will try to re-write my plug-in, if
> you're positive that my concerns are unjustified.
>
> Regards,
>
> Lukas
> --
> https://code.launchpad.net/~koschmieder/zim/zim/+merge/257936
> You are reviewing the proposed merge of lp:~koschmieder/zim/zim into
> lp:zim.
>

Hi Jaap,

If I understand you correctly, then your main issue is the fact that my plug-in loads the entire notebook in memory. Would you allow me to keep my own search function / rating system if I got rid of the problematic page buffer / results cache?

> With respect to the rating system, I'm open to improvements. Just specify
> in more detail what you think should be different in the rating and we can
> have a look at it. My objective is putting most relevant results on the
> top, but I didn't optimize it much.

My rating system is inspired by Tomboy/Gnote. The search function prioritize "title matches" over "path matches" over "page matches". This concept may sound simple but it has proven to be useful in my daily routine. However, I'm not sure if this method is suited to improve our default results system.
With respect to improvements, it would be nice if ParseTree could also provide a case-sensitive count function.

> Have you looked at the search language we use? If you use keywords for
> searches, searching names will be really fast.

My plug-in iterates over all pages in the notebook, for each page greps its parse tree and then uses the count function to get the number of matches. Is there a faster alternative?