Christian Boxdörfer

Results 243 comments of Christian Boxdörfer

I need more information about this, is this about pinyin input? If so I don't think I'm able to support it anytime soon, unless it's easy and quick to implement....

The formats are only specified by the source code at the moment. However they're not too complex and by looking at the db_load function it should be quite straight forward...

Yes, that's a known issue when the highlighted part applies to both file name and path. It's not even exclusive to regex mode, it also happens with wildcards. I'll see...

> Is this result really as it should be?: ![ksnip_20220104-170340](https://user-images.githubusercontent.com/13977359/148087763-b189fd67-5e2d-4566-a5a6-8871fa7b6378.jpg) Yes. > My expectation was, that it would not find for example `$I8CTTC9.pdf` because the regex command says: "Do find...

> It looks like I have found another case, where FSearch does not mark correct bold, what it has found: ![ksnip_20220101-153704](https://user-images.githubusercontent.com/13977359/147852995-d9a80b0b-895e-43fd-bca0-0a1c0aa62121.jpg) > > Shouldn't both "a" be bold in "aas1901"...

> Thank you for your answers. > relating to the example with .*[^pdf]: > Oh yes, I see. Thank you. Of course this works in FSearch as it should. Sorry....

All those issues (mismatching regex search results and highlights and issues when highlighting applies to both path and name) have already been fixed in the 0.2alpha builds. I'm planing to...

0.2 with the fixes is no available. Closing the issue.

Honestly it might happen earlier than I thought. There are some parts of GTK+ which are just so annoying to work with (e.g. the performance of GtkTreeView, which is basically...

@nathan2423, thanks for the reminder. I'll update the GTK+ version requirements.