Plugin-enabled fulltext search on first search page

[Lefteous]

Thank you for adding plugin-enabled fulltext search on first search page

Remarks:
- Setting a title for a definition seems a like a good idea. There are quite a few dialogs in a row though.
- Not just fulltext fields can be added to the search. This makes it quite powerful. Semantically it's strange to be able to search for all kind of stuff although it's just about finding text in files though.
- Fulltext search fields have an exclamation mark prefix which is fine. A little checkbox to filter for fulltext fields would be highly welcome.
- It's very nice that the last used setting is restored when opening a new search.

Questions:
- What is the priority of text searches? There is now simple built-in search, 'office file search' and the new plugin search. Can they all be combined or is just one executed?
- I actually have no idea how other fields work. What must be entered to find a file matching [tc.archive]? Again, semantically it's a bit weird.

[ghisler(Author)]

- What is the priority of text searches? There is now simple built-in search, 'office file search' and the new plugin search. Can they all be combined or is just one executed

All checked are executed until there is a match, e.g. Text, Unicode, plugins in the order they are listed.

- I actually have no idea how other fields work. What must be entered to find a file matching [tc.archive]? Again, semantically it's a bit weird.

It's not that weird, just search for what the field would return when used e.g. in a custom column or multi-rename tool. TC uses the same function to convert the field to text, then searches for the search string in that text.

[milo1012]

I can't say that I'm happy with the current solution.
Like I already mentioned in this thread: I just don't have a demand to "pre-filter my filter" with a file type mask. Every time I want to quickly change a single (or a set of) filter(s) I need to click/navigate through the file type mask. It's just redundant and cumbersome to alter such filter set.
The ability to use wdx fields might be more prominent to be seen by users now, but besides that I just don't see any improvement in terms of "access time" for activating the wdx fields in the search, especially compared to simply switching to the Plugin tab. On top of that, most wdx plugins have a detection mechanism anyway, so I end up using "*" as a file type filter most of the time anyway.

Suggestion: Adding the ability to switch the file type filter off, and just using the search mask from the main search dialog.
That way one could quickly access the wdx fields w/o navigating through a bunch of menus.

[Lefteous]

2ghisler(Author)

All checked are executed until there is a match, e.g. Text, Unicode, plugins in the order they are listed.

OK fine. What happens in the following situation. I have 10 files, 5 are plain text and five are PDF. I search for 'ansi' and 'plugin'. In this case I would expect that TC searches in the text files and xpdfsearch searches the PDFs.
Is the normal text search used for PDFs in this case or this the filter entered in the definition used for avoiding this?

It's not that weird, just search for what the field would return when used e.g. in a custom column or multi-rename tool. TC uses the same function to convert the field to text, then searches for the search string in that text.

Thanks for the clarification.

I still think it's weird. I could check text and plugin search for tc.archive and enter 'yes' as search term. I don't see how this could make sense.

[ghisler(Author)]

Suggestion: Adding the ability to switch the file type filter off, and just using the search mask from the main search dialog.

Just use *.* as your filter! TC does use the mask from the main search dialog! The filter is just additional!

For example, if the main filter is Letter* and the type filter is *.pdf for the pdf plugin, then TC will only send Letter*.pdf files to the plugin!

[milo1012]

Just use *.* as your filter! TC does use the mask from the main search dialog! The filter is just additional!

For example, if the main filter is Letter* and the type filter is *.pdf for the pdf plugin, then TC will only send Letter*.pdf files to the plugin!

Yes, I'm aware of that.
It's just that I may want to quickly try different plugin fields. With the solution we have now, I still have to confirm the filter extension every time, plus navigating to one filter field and using "Edit" before that.
(sure, I could build several presets, each representing a different plugin, but this is just a redundant piece of work IMO)

So making the whole preset list optional and just quickly adding plugin fields without any "file type filter" ("preset") before that might come in handy.

[Lefteous]

2milo1012
I think your use case is really different. While my use case is clearly 'use plugin x _everytime_ instead of built-in text search for *.a files and plugin y _everytime_ instead of built-in text search for *.b files' you are looking for a more flexible solution that would probably lead to using different fields for every search.
I think both use cases make sense but they should be solved differently. I don't think there is one solution that solves both.

[ghisler(Author)]

For his use case, it's probably better to go via the plugins tab. I'm using both now, depending on what I need to find: I have first page search filters for PDF and comments, and do other searches for specific plugin fields via plugin page.

[Lefteous]

2ghisler(Author)

What happens in the following situation. I have 10 files, 5 are plain text and five are PDF. I search for 'ansi' and 'plugin'. In this case I would expect that TC searches in the text files and xpdfsearch searches the PDFs.
Is the normal text search used for PDFs in this case or this the filter entered in the definition used for avoiding this?

Can you explain how it works?

[ghisler(Author)]

It depends how the user adds the plugins to the search text section: If he adds
*.pdf -> xpdfsearch
*.txt *.html *.whatever -> textsearch

Then TC will use the xpdfsearch plugin for pdf files, and the textsearch plugin for the other files. If he defines
*.pdf -> xpdfsearch
*.* -> textsearch

TC will use xpdfsearch for pdf, and textsearch for all other files, but also for pdf if xpdfsearch doesn't return a positive result.

If he defines
*.* -> xpdfsearch
*.* -> textsearch

TC will first use xpdfsearch on all files, and if it fails to find the text, use textsearch. That wouldn't make much sense in the case of xpdfsearch, but the user may want to use two different text search plugins.

[Lefteous]

2ghisler(Author)
Thanks for the detailed reply. It's important to know how the plugin-based search works in detail.

I was asking for something else though. What happens in the above mentioned scenario where the internal text search is also checked? Here is a detailed example.

1.txt (internal search used)
2.txt (internal search used)
3.txt (internal search used)
4.pdf (internal search used???, xpdfsearch)
5.pdf (internal search used???, xpdfsearch)

[X] ANSI charset
[X] Plugins *.pdf -> xpdfsearch

[ghisler(Author)]

Yes, TC always tries the internal search first, and if it fails, it uses a plugin. If you don't want that, use an external text search plugin and uncheck the internal searches.

[Lefteous]

2ghisler(Author)
What about checking for matching plugins first and only use the internal plain text search only if no plugin matches? If there is a plugin-based search defined for *.* disable the text search options.

[ghisler(Author)]

If there is a plugin-based search defined for *.* disable the text search options.

This would contradict what the user sees (internal text search options are checked, but not used at all).

[Lefteous]

2ghisler(Author)
You would have to communicate through the UI that the internal options are unavailable. By entering *.* as a filter the user has actually unchecked all the internal options.