REQUEST: filter highlight

I would like to propose one addition: an option for the filter [when putting a search value in the box] not only be able to cut out [hide] unwanted files, but to somehow highlight them on the list of [all] displayed files

The old method should be retained. But let's say clicking on the "Filter" sign could switch it from old method of filtering to the new one: from hiding unwanted files to highlighting the wanted ones

Does no one finds this useful?

Filtering is not searching.
Filtering means that you reduce a data set by certain criteria and you deal with all the records that match the criteria.
Searching means that you keep the originally loaded data and scan the data for certain criteria and then jump from one hit to the next.

When I filter data, I prepare the data for further treatment. I do not need any highlight as all the records would be highlighted somehow as they all match the criteria. Otherwise the record would not be included in the list.

Filtering is very powerful for huge amounts of records. Searching is absolutely tedious for huge amounts of records as you may jump through hundreds or even thousands of hits.

The data that is compiled with filtering may be thousands of records apart. So it would take hours of scrolling to find the next highlighted entry.

In addition I see technical and logical problems with the filter hightlights. THis may be straightforward for simple filter criteria but tricky for more complex criteria or criteria that refer to fields that are not displayed or criteria that test for non-existing data (e.g. %bpm% MISSING).

There has been a discussion in 2010 on a similar topic:
/t/10820/1

The response back then has been just as reluctant as this time. So apparently there is no urgent need for this.

Since when is there a Search function? As a relative outsider, I couldn't believe that MP3Tag had no Search (or Find) function and that the only way to find something was to filter for it. I still can't. So if there is now such a function, please tell me.

I requested a Find function some time ago and some interest was shown in it. Please see this post where I argue in favor of such a function: Poll: Does Mp3Tag need a Find function?

Since when is there a Search function? As a relative outsider, I couldn't believe that MP3Tag had no Search (or Find) function and that the only way to find something was to filter for it. I still can't. So if there is now such a function, please tell me.

I requested a Find function some time ago and some interest was shown in it. Please see this post where I argue in favor of such a function: Poll: Does Mp3Tag need a Find function?

Yet I got the distinct impression that the barons of this forum are against the implementation of a Search or Find function (let's be clear: a function that searches the entire library), and I continue to get that impression reading this post.

I'd be happy to start the argument again. - Les

And what if there is no other method of evaluation than a manual / visual [searching]? That can't be done with some [filtering] script because you can't put IA in it or a your detailed knowledge?

The only workaround is to create some temporary column and putting in them, probably after more than on filtering, some characters. And that is a limitation and a drag- I've been there. Sometimes I had 3-5 columns, each meaning different thing, with different sign in every column. And I thought to myself "if only I could filter also by color, this would be much easier and so much less erroneous"

I shall make it less reluctant right away

Sorry, I simply do not understand it. What does "because you can't put IA in it or a your detailed knowledge?" mean? What is "IA" and where do you look for "detailed knowledge"?

I think that you can also create filter expressions that grow to match just the right files.
Yet, if you want to select some files out of regular filtering patterns and then re-use them for other snapshots of your data, then, yes, you have to enter data in separate fields to reflect this previous choice. But this more or less arbitrary selection could also not be covered by highlighting.

I would say: any file that is displayed after applying a filter matches the criterion. And as the filter is shown at the bottom for easy reference, highlighting is not really required.
Highlighting would even be impossible or meaningless if you filter with the operator "NOT"
e.g.
NOT %_filename% MATCHES "^\d+ "
to find those that do not start with a number. How do you highlight something that is not there? Would the lack of highlighting be irritating? Or would you assume that, as the file is shown in the list, it matches the criteria? If so, we have the state as it is today.

Anyway: everybody is free to propose changes to MP3tag.
My intention here is: how can existing functions be used to support an individual workflow or what can I suggest to achieve a certain goal. This suggestion sometimes does not follow the OPs original path. But what is more important - the way or the result?

Like when I'm looking for errors and scripting will not help or help in a limited way. Especially when a tag field [like COMMENT] has hundreds of signs among which there are possibly dozens of those that I may need to seak to- and then stop, evaluate with my eyes, think and only then take action or decided to leave it be as it is

And if I could combine some narrowing down achieved by the old filter and the highlighting of certain values in those pre-selected files, then It would make the process quicker thus more efficient. And it does not have to happen at the same time, because I can create a playlist from the first filtering or create some temporary column, to be used by the with the second process

[But two different filters working simultaneously would be something to consider, once the highlighting option is implemented. One revolution at a time]

You simply do not highlight this that cannot be highlighted and somehow indicate such syntax error or whatever you want to call it

And ask yourself this: what will happen if you put in the filter box for example

"$if($eql(%title%,%_filename%),1,0)" IS "0instead of
"$if($eql(%title%,%_filename%),1,0)" IS "0"Nothing?

Or if you do put down in it correctly

"$if($eql(%title%,%_filename%),1,0)" IS "0"but then also nothing happens, because all TITLEs and FILENAMEs are the same?

So maybe Filter should be abolished altogether, because right now it cannot show that it cannot show results for incorrect expressions and it doesn't indicate that there is nothing to be shown with a given criteria? And it also doesn't show that it is still computing more complex expressions applied to many files and not simply not showing results because there is nothing to be shown!

You say: there is now sense; and there will be problems

I say: I would know how to put it in use; and the problems are to be delt with at the pre-implementation stage

IMHO these are completely different topics that have nothing to do with highlighting.

It is possible already today to use several filter criteria at the same time as there is the AND and OR operator.

Indicating syntax errors is a completely different topic, I think. And in particular syntax errors would not be avoided by highlighting as the highlighting would work only after a syntax error free expression has been entered.
What I see lurking behind this: apparently it is possible to enter criteria and not trust them, so that the highlighting should show: "This is what I found - is that what you intended?".
MP3tag does not check the plausibility of the criteria, this is still up to the user. And even the lack of results originating from a syntax error says nothing more than "there are no matches for this expression". If you are not satisfied with this result, you have to modify the filter. Still no highlighting required.

I agree that is would be nice to have a progress indicator during filtering, esp. with large amounts of records. I think there is actually a style guide for this: if a process takes longer than 2 seconds, the "busy" cursor should be displayed.

This needs to be a must

We are whole years away from being able to say "computing power of a even a low end PC is so high that even chewing 50 000 files even with very complex expression will not take anyone more than 2-3 seconds"