Multi-file search File filter not restricting search as expected

[Brian Forte]

Gentlefolk,

I feel like I’m missing something obvious here.

1. Select *Search → Multi-File Search…* (or press ⌘⇧F)

2. Find: [search term here]

3. Search in: My Files & Folders > git-repos — ~/path/to/folder

4. File filter: asciidoc files

* Filter name: asciidoc files
* Matching: 🔘 Any term may match (“OR’) ⭕️ All terms must match (“
AND’)
* [Name extension] [is] .adoc

Start the search.

In a very few seconds, the ‘Searching’ value in the Search results
window presents “file-name.zip” as the file currently being searched.

A file with a name extension of `.zip` file does not match the
filter’s single requirement.

## Notes

1. Changing the file filter’s *Matching* value to AND does not change
the filter’s behaviour.

2. Changing the Name extension string to be matched to ‘adoc’ (ie,
removing the pre-pending full-stop) does not change the filter’s
behaviour.

I know .zip files are archives containing other files, and said other
files could, theoretically, be AsciiDoc files.

But, in both the every-day sense, and in the
what-commands-I-use-when-I’m-in-the-shell sense, a .zip file is *not*
a folder.

To my mind, setting the condition as file-extenstion = .adoc should
mean only files with that filename extension will be searched.

Hence my initial statement: I feel like I’m missing something obvious
here.

Thanks in advance. Especially thanks if it is obvious (even if only in
retrospect).

Regards,

— bforte.
--
Brian Forte
<bfo...@adelaide.on.net>

[Rich Siegel]

The “name extension” does not include the period, so omit that.

You also have turned in “Search compressed files” (behind the Options button), which enables searching in Zip archives.

R.

> On Oct 2, 2024, at 11:40 PM, Brian Forte <bfo...@adelaide.on.net> wrote:
>
> Gentlefolk,

> --
> This is the BBEdit Talk public discussion group. If you have a feature request or believe that the application isn't working correctly, please email "sup...@barebones.com" rather than posting here. Follow @bbedit on Mastodon: <https://mastodon.social/@bbedit>
> ---
> You received this message because you are subscribed to the Google Groups "BBEdit Talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bbedit+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/bbedit/20241003130728068987.10e28bdb%40adelaide.on.net.

[Brian Forte]

Rich,

> The “name extension” does not include the period, so omit that.

[Assume standard rage against file-name extensions has been expressed
here.]

The full-stop is, strictly speaking, the delimiter character between
the file name string and the file name extension string.

In day-to-day use, however, and at least in the software-centric
technical circles I work in, the noun phrase ‘filename extension’
means the characters after the full-stop **and** the full stop.

That is, people talk about `.zip` files and `.md` files and `.json`
files, and `.ts` and `.c` files. And they pronounce the full-stop (as
‘dot’) when speaking. And they write the full-stop as per the
examples above.

Which is a linguistic argument, at least, for ‘Name extension’ to
treat

.string

and

string

as equivalent.

> You also have turned [o]n “Search compressed files” (behind the Options

> button), which enables searching in Zip archives.

Here was the magic (and entirely obvious in retrospect) checkbox I’d
overlooked.

Many thanks for this.

[jj]

Sometimes software gains wisdom beyond the intentions of its designers.
As far as I can tell in my copy of BBEdit, both forms
"[Name extension] [is] [adoc]" and
"[Name extension] [is] [.adoc]" yield the same result.
Nevertheless, the recommended version is always preferable, so I will correct the dozens of filters I have been using for years that used the dot extension form.

🤗

Jean Jourdain