Select SIMILAR doesn't honour multipart_extensions

Given the list of files:


Select SIMILAR on the double-extension .test.txt will only select that very file. Same goes for .test2.txt.

However, running the command on the single-extension foo.txt will select all three files, despite multipart_extensions having the last two defined as individual extensions.

Shouldn't the command be treating the double-extensions as such? i.e. Only the plain .txt should select when running the command on it.

The docs' description reads:

SIMILAR: Selects all files with the same file extensions as the currently selected files.


System information:

- Directory Opus v12.23.1 Beta x64 Build 7710
- Microsoft Windows 10 v20H2 OS Build 19042.804

Seems debatable to me. All three files have .txt extension as an extension in this case.

Multi-part extensions were introduced for things like xyz.part01.rar files where you want to separate the xyz and .part01.rar parts of them for extracting (you want the folder to be called xyz, not xyz.part01) and renaming (you want the .part01.rar to be left alone when preserving extensions).

For selections, I can see cases for it working both ways, but I'm not sure it really matters, at least without a real world example.

Note that you will find several places in Opus that only use the last extension part (usually for reasons of speed and simplicity, since getting the list of multi-part extensions involves calling plugin DLL code). The multipart_extensions setting is not intended to be completely pervasive throughout every part of the program; only in the places where it's really useful.

In my case, I've developed a system of leaving notes in filenames for folders/files instead of having to open documents to read a simple line denoting some relevant info. My notes have their type annotated, e.g. .fix.txt, and I prefix their filenames with a character for sorting purposes. Keeping my notes ending in .???.txt rather than simply using .fix means they all remain openable in text editors if need be. These double-extensions also make colouring them based upon their severity/meaning a thing that Opus allows me to do.

It's unlikely I will often need to select all my .fix.txts at once in a folder (should a folder have more than a couple), but I can see wanting to select (and then delete) all .txt files in a folder, knowing I won't be touching my notes, which this function currently fails to do. I could potentially make a script for this, but it'd just be more convenient to explicitly primarily select a normal text file, or one of my notes, and know my notes will or won't be included by the Select command, prior to a keyboard delete.

I'm hoping to use the Double-click on file display background feature to select. If it's possible to write multiple commands on one line, or use a load-script command (I don't know), maybe it's possible to select similar files, then de-select those I never want to select when selecting .txts? This does feel like a bit of a workaround however, but maybe it's something I could settle for if my use case isn't compelling enough.

If it is however, my issue could be solved by something like Select SIMILAR=multipartexts. If it weren't for the speed and simplicity concern you mentioned, I think it'd make more sense for that to be the default and something like Select SIMILAR=lastexts to be introduced instead (to mimic current behaviour). But swapping the default could possibly disrupt people's established workflows.

I do understand that this feature was added later to cover some specific use cases, and it could be that the cost of covering this use case doesn't warrant a call to the DLL you mentioned every time.

I do still think it's a bit odd from a UX perspective that a multipart extension will be honoured when it is the one that is pre-selected before the select command, but when it isn't, it's treated as if a single extension.