Can "FAYT" highlighting be opened up to scripting?

I think FAYT was and is exclusively designed to be triggered by the keyboard, not by scripting. At least I didn't find a way to do it when I was skimming through the Opus manual.

But I do use it for other purposes. Although automatic file selection when entering a folder can be scripted via a Script Add-in (as this example created by Leo illustrates), selected files are lost when you click into a folder. Yet when FAYT's "Find mode" is set to "Keep highlights visible after field closes (Esc to clear)" and you type something that corresponds to certain files, the coloring within those file names remains remains permanent (even when you open files in that folder, etc) - until you hit the Escape button. Which is the reason why I use this to quickly see my "sidecar" files in any folder I open.

Explainer (just to illustrate my case properly) : What I call my "sidecar files" are text files with the same name as its original file (a movie file, music file, pdf, ebook, or whatever) except it has a specific "sidecar" extension. An example (with FAYT-selection on "sidecar") :

sidecarfle

This is VERY convenient for me, as it gives visibility to these specific files (which I'm using instead of "descript.ion" files since a while) and this visibility largely remains in tact watever I do in those folders. These files are also close to their 'original' when the list is sorted alphabetically, and even whien I sort on modify date (because my Opus editor dialog always adapts their modify datetimestamp to be identical to its 'original') - but those are just marginal details. My point is about giving those specific files more permanent visibility. And it works great. It also shows matches in the scrollbar (when that option is set in the FAYT find mode).

Yet, the way I've implemented this in my script add-in, which is called whenever I enter a folder, is a little awkward:

DOpus.SendKey("s");DOpus.SendKey("i");DOpus.SendKey("d");DOpus.SendKey("e");
DOpus.SendKey("c");DOpus.SendKey("a");DOpus.SendKey("r");

Is there a way to open up this highlighting feature for scripting?

E.g. something like this:

var cmd = DOpus.Create.Command;
cmd.RunCommand('Select PATTERN="sidecarfile" HIGHLIGHT="#ff0000"');

Not to mention the more trivial possibility to tune it with additional keywords like "keep" (to keep the highlighting active) and "matches" (for showing the matches in the scrollbar). Or those could be made the same as for FAYT highlighting. Also, hiding the type field in this case would be great.

It's just an idea. I'm seeing a powerful mechanism which has only been given limited use in the FAYT scope.

CLI QUICKFIND .sidecarfile is the command.

Although I would use another approach and set up a wildcard label on *.sidecarfile to change the color of those files without having to run a command.

Ah, yes, a CLI command. Thanks.

Wildcard labels... I use them for quickly seeing very recently downloaded files, for instance, they're highlighted for a short time. But the advantage of hghlighting specific parts of files is that precisely the partial nature of it: they instantly identify the specific nature of that particular file.

It would still be an improvement if it were possible to use a specific, dynamic color for different cases, e.g.:

var cmd = DOpus.Create.Command;
cmd.RunCommand('CLI QUICKFIND *movie* HIGHLIGHT=#ff0000');

Not to mention the possibility to not show the FAYT box at all (parameter "invisible"?) - or to make it close immediately (e.g. "nosearchbox"). And a "noscroll" parameter to forbid scrolling to the first found entry, just do the highlighting - because by no means is auto-scrolling the obvious purpose of highlighting files.

And are combinations possible? I always find it strange that in some situations we have powerful filters (e.g. FILTERDEF) while in other situations we have not.

How about:

var cmd = DOpus.Create.Command;
cmd.RunCommand('CLI QUICKFIND noscroll nosearchbox HIGHLIGHT=#ff0000 FILTERDEF name match *movie* or name match *film*');

Since what you're trying to achieve is some kind of visual highlting without a real need for selection (as far as I understand), Leo's suggestion to use a label looks like the best option here.
You could even use a label that sets the background to a colour close to the one you use for selection so it provides an effect close to the selected state you have today.

I tend to use a lot labels to identify file types (e.g. based on their extension), and it really is powerfull when you look into a "busy" folder: the PDF amongst Excel files jumps right at your face, or the JSON file in the middle of other development files (JS or whatever).
Using the label is also effortless as it's done right when you get into the folder or expand a subfolder without having to do anything.
Anyway, that's what I would do in that kind of situation.

Existing mechanisms are okay, but I do use labels a lot - both for colors and adding icons (usually permanent ones - those that are saved in NTFS/ADS, and a few dynamic ones.

The partial coloring however adds a very different kind of visual. To make its usefulness obvious: you could (IF the query allows for RegEx) just colorize the year in all your movie files if you - like me - have their publishing year in the filenames. Obviously you don't want to color all your movie files in green because they all have a year in their name!

I understand how useful it would be to be able to only highlight certain part of filenames, but that feature does not exist (yet?? :slight_smile: ).
I was just saying what I would do with the tools at hand right now if I were in this situation.
I won't try and convince you as you seem to know quite well how labels can help.

Other solutions you can use right now are to show a status icon for those files (stands out without changing the whole row), or using a custom Evaluator Column which shows some file extensions (or whatever icons and/or strings you want to use) in different colors.

Support++ what I take to be the OP's implicit feature request for a labels feature with partial highlighting.

I understand your viewpoints. Still, it seems obvious to me that partial selection is a more dynamic process than, let's say, defining icons in the Opus label setup and assigning those by setting up filters. I use label icons more for more general purposes (label icons indicating "important", "follow up", "watched partially", etc. etc. - these aren't related to the name of a file). For those things that I have already in filenames, I don't want to extend my 25 label icons with again new ones (which will add up enlarging the column in which they are displayed). Not to mention there's some serious processing going on in DO to read those labels from NTFS/ADS in a long list of files.

My example of a movie year is the most obvious case where CLI QUICKFIND is a far more interesting, more powerful, and more dynamic way of visualizing these (however, it requires the possibility to use RegEx in a query).

Probably not what you want but as markup evaluator column:

return (operation == "markup") ? regexs(name, "_sidecarfile", "<#000000 #ffffff>_sidecarfile</font>") : name


I use some eval columns, although I don't understand how this operation=="markup" test works.

It would also be pretty heavy-weight to filter the filename column in this way all the time. But it's a nice hint because it does address the topic at stake.

But that is what you are asking for.

Haha, nice try! You're wriggling your way out of the challenge! :wink:

But I'm pretty certain the highlighting mechanism would be light-weight compared to an eval column.

That's not the highlighting part that you're asking for that is not lightweight, it's the identification of what is to highlight (first the files that match, then the part of the filename that matches).
When you're searching matching files, you're basically parsing every filename in your display, whatever the method (eval column, label, quick find, ...)

Eval columns cannot display anything in the filename column before the filenames were processed first. The highlighting mechanism however comes on top of the display, when the file list is already displayed, unprocessed and fast.

Look, I'm fine with how it works now. The CLI query was what I was looking for. A RegEx search would of course sharply improve the possibilities to get much more out of it.