New WDX field custommatch flag + ContentCustomMatch func

[MVV]

Currently there is no easy way of passing some parameter to content plugin during searching, so we need such a way. Fields of ft_custommatch type should only support one matches operator that will pass entered text to ContentCustomMatch plugin function, and plugin should check if this string (it may be some command, text or just another file name for e.g. checking if this file exists in the same dir) can be applied to the given file. It may be a much more powerful way of searching for text than returning entire file text to TC (which may be ineffective for large files), or it may be a way of performing plugin-specific function with some input parameters.

E.g.:

Code: Select all

someplugin.RawContents matches "abc"
someplugin.DirContains matches "descript.ion"
someplugin.DirContains matches "..\desktop.ini"
someplugin.ImageSize matches "small or medium"

I believe there will be much more applications for such function.

[Hacker]

Support++.

Roman

[Lefteous]

Sounds like a nice idea to me.
We should first clarify how this could be used from a user point of view. Currently the user has to enter a plugin field, an operator and a value. For me it seems plugin field and value would be the same but what is different is actually the operator.

The next question would be if the operator is really field-specific or can be used for all content fields. I currently don't see a reason why these operators cannot be provided globally. This would make the whole thing much more flexible and it's also the more logical solution.

So a plugin field that returns a string 'sometext' would be returned by the plugin. Now TC would call the custom operator called e.g. 'contained in this folder' that checks if a filename with such a string is contained in the folder belonging to the file.
So for the user it would be plugin.field 'contained in this folder' 'sometext'
From the programmers view the function would have at least these params: filename, type and value (void* fieldValue). It would of course always return booleans.

In the end convincing Ghisler is only possible with real-world use cases. If there are only a few he can do it internally. If they are to special he might argue that not many users would use it. A plugin API only makes sense when it's something inbetween.
I think some operators could really be added internally like 'starts with' and 'ends with' as I suggested a while ago.

[MVV]

So you suggest to add user-defined operators instead of special fields? What will field name do in your case?

And I don't understand why would plugin field and value be the same - field describes an action and value is a parameter for that action...

I thought about an operator that can be used for all content fields, and ContentGetSupportedFieldFlags function could export a flag for fields supporting this operator, in such case parameter could define e.g. some kind of custom format string (for fields that export values other than boolean). I don't know though will it be useful or not.

[Lefteous]

So you suggest to add user-defined operators instead of special fields?

Yes

What will field name do in your case?

Same as now

And I don't understand why would plugin field and value be the same - field describes an action and value is a parameter for that action...

Why do you think I do? Of course a field is a field and a value is a value. The connection is that the field retrieves the value. Nothing should be changed about this. This would be confusing.

I thought about an operator that can be used for all content fields, and ContentGetSupportedFieldFlags function could export a flag for fields supporting this operator, in such case parameter could define e.g. some kind of custom format string (for fields that export values other than boolean). I don't know though will it be useful or not.

Try to think about ther use case first and then we can talk about how it could work.

[MVV]

Same as now

Please provide an example where field name and operator name both have sense. In my mind two user-defined names are redundant so they could be merged into one field name so it would be enough one specific operator.

Why do you think I do? Of course a field is a field and a value is a value. The connection is that the field retrieves the value. Nothing should be changed about this. This would be confusing.

In my case value would be used as a parameter for the field, and result would be boolean, while in standard case value is compared with field result by TC.

The first use case is searching for specific files in same dir (this topic). With such feature it could be solved like this:

Code: Select all

someplugin.DirContains matches "DTAR_08E86330_4835_4B5C_9E5A_61F37AE1A077_DTAR"

[ghisler(Author)]

For the user it's better to have separate field name and operator. For example, the operator can be "contains", "contains, ignore case", "does not contain", "regular expression" etc. etc. Now imagine a plugin with 20 fields, and you would have to add 8 or so operators as fields - this gives a list of 160 fields.

The question is why does the plugin have to check for the field instead of returning it to TC, so TC can check it? Is there any technical reason to do this? Can you give me a concrete example where this would be useful? Because the downside is that the plugin author would then have ti implement all these operators by himself.

[MVV]

ghisler(Author),
E.g. we want to check if a file exists near our file: if we let TC check, we need to return entire directory listing (which can be huge in some folders, and it will be returned for every file) while in case of passing file name to plugin it would be a quite fast check.

Another example may be checking if a file contains some not-adjacent values (e.g. we search for files w/o null bytes)...

So benefits of such parametrized operator are mainly in cases when a plugin should return too much data (or too strange data) to let TC check something instead of just checking it by plugin itself using passed parameter. And, these are special fields that don't need usual TC operators, only special ones, so a plugin writer would need to support only required operators.

[ghisler(Author)]

I see - that makes sense. For such fields, it would be best to allow custom operators provided by the plugin, and not require support for standard operators like "contains".

[MVV]

So we need at least some special field flag (field value must be ft_boolean) and a function that will process field parameters.
Also, if we need multiple operators for a field, we need a way of enumerating operators. Though I think that one generic operator for such fields would be enough (field name can be descriptive enough).

[ghisler(Author)]

There are other possible problems, e.g. the comparison could take several minutes, which would completely block TC. Therefore some sort of background processing would be needed...

[MVV]

Well, you can use the same ft_delayed+CONTENT_DELAYIFSLOW scheme here.

[MVV]

I've recalled that feature again but it is still not implemented. Would be nice to see it in TC 10.

I think that custom operator name(s) may be returned in Units field for such fields (because such fields are not for displaying data), since there is no need to change function interfaces.

[MVV]

So, isn't it a good time to extend API?

[ghisler(Author)]

This has actually been added recently:
01.03.21 Added: Content plugin interface: New flag contflags_fieldsearch allows to handle the search within the plugin instead of returning the value to Total Commander. Includes 3 new functions: ContentFindValue, ContentFindValueW and ContentGetSupportedOperators (32/64)

The new functions are described here:
https://www.totalcommander.ch/beta/contentpluginhelp212_chm.zip

I solved the operator problem with the new ContentGetSupportedOperators function, so you only need to implement the operators you need.