🔎 ISE Search — How search works

This one page is shared by all five search dropdowns — ISE (forum posts), ISEpdf (PDF attachments), ISEmisc (text/code attachments), ISEmega (Posts + PDF + Misc, merged into one result list), and ISEmedia (image/video search by meaning and caption/filename keyword, not full-text). Reach it any time by typing /help as your search query, or via this same link shown at the bottom of every results page.

The short version (as of v9.5): ISE, ISEpdf, and ISEmisc behave the same way for quoting, case, and wildcards — normal words are case-insensitive, */? wildcards work on bare words in all three, and "double-quoted phrases" are case-sensitive exact matches. Wildcards do not work inside quotes in any source — see Wildcards below. The one remaining difference among those three is what a phrase can check: ISE (posts) and ISEmisc check real adjacent-word-order phrases against actual stored text; ISEpdf can only check that every word in the phrase appears somewhere on the same page (see the note under ISEpdf below). ISEmega simply runs your query against those same three sources and merges the results — it doesn't add its own quoting/wildcard rules, it inherits whatever each of the three does on its own. ISEmedia is architecturally different from all four of the above and does not use quoting or wildcards at all — see the dedicated ISEmedia section below.

Quoting — what actually happens in each source

Style ISE (posts) ISEpdf ISEmisc
No quotes
e.g. heroin
Normal word search. Case-insensitive, fast index lookup. Normal word search. Case-insensitive (as of v7.4 — the stored index still isn't lowercased, but matching now folds case at search time). Normal word search. Case-insensitive, fast index lookup.
"Double quotes"
e.g. "opioid crisis"
True phrase match. Exact, case-sensitive, literal substring — spacing and punctuation inside the quotes must match exactly. Supported (as of v7.4), with a real limit. Case-sensitive, but only checks that every word in the phrase appears somewhere on the same page — not that they're adjacent or in order, since the index doesn't store page text or word position. Treat it as "these words, together on one page," not a true phrase. True phrase match (as of v7.4). Case-sensitive, real literal substring against the file's actual stored content — same guarantee as ISE (posts).
'Single quotes'
e.g. 'heroin'
Known gap — avoid. Not recognized as a phrase marker. The quote characters become part of the literal search string, which almost never appears verbatim in real post text, so this will usually return zero results. Not supported. Same as ISE above — avoid. Not supported. Same as ISE above — avoid.

Wildcards

* matches any run of characters, ? matches exactly one character.

SourceWildcard support
ISE (posts)Supported (as of v7.4.1). Post bodies and subjects. Case-insensitive, matching this source's normal case-insensitive word matching.
ISEpdfSupported — content and filename/topic search. Case-insensitive (as of v7.4), matching this source's normal case-insensitive word matching.
ISEmiscSupported — content and filename/topic search. Case-insensitive, matching this source's normal case-insensitive word matching.

Wildcards inside "double-quoted phrases" are not supported in any of the three sources — a */? inside quotes becomes a literal character in the exact-match/phrase check, which will almost never appear verbatim in real text. Wildcards only work on bare, unquoted words.

Example: *aud* in any of the three sources' content search matches any indexed word containing "aud" — "claude", "audio", "fraud", etc. Example: methad* in ISE (posts) matches "methadone", "methadose", etc.

A term with no */? in it always uses the faster exact-match path — wildcards only trigger the slower full-scan when actually present in what you type.

Sorting results

By default, results are ordered by relevance score (see "Why is this ranked #N?" on each result card). Typing one of these as part of your query re-sorts the results you already got, without changing which results matched:

CommandEffectWorks on
/sort newestNewest first, by date posted.ISE, ISEpdf, ISEmisc, ISEmega, ISEmedia
/sort oldestOldest first, by date posted.ISE, ISEpdf, ISEmisc, ISEmega, ISEmedia
/sort newmodMost recently edited first. Posts that have never been edited fall back to their post date.ISE only
/sort oldmodLeast recently edited first (same fallback as above).ISE only

newmod/oldmod only work on ISE (forum post) search — PDF, Misc, and Media attachments don't have an "edited" concept the way a post does, so there's no modified date to sort ISEpdf/ISEmisc/ISEmega/ISEmedia results by. On ISEmega specifically, a newest/oldest sort also changes how results from the three sources are combined: normally ISEmega interlaces Posts/PDF/Misc results to keep all three sources represented even when one scores much higher than the others; a date sort instead merges all three into one straight chronological list.

On ISEmedia specifically, a real search term always still has to match — even under /sort newest/oldest — before date-sort reorders the matches. This is different from how it might sound by analogy with the other sources: ISE/ISEpdf/ISEmisc/ISEmega already only ever see matching items by the time a sort is applied (their underlying index lookup filters to real matches first), so their date-sort "just" reorders what's already a matching set. ISEmedia's ranking starts from every indexed image/video as a candidate (it's a similarity search, not a word-index lookup), so as of v1.2.0 it explicitly requires a literal caption/filename/subject keyword match before applying any sort — including date sort — so a query like /sort newest brown only shows items that actually match "brown," newest first, rather than every recent upload regardless of relevance.

Sorting applies after search — it never changes which posts/PDFs/files/media match your query, only the order they're shown in.

The five sources at a glance

SourceSearchesResult links to
ISE Forum post bodies and subjects, forum-wide. The matching post directly.
ISEpdf Text extracted from PDF attachments, plus PDF filenames and their topic's subject line. The PDF opened in the PDF.js viewer at the matching page, plus a "Jump to post" link.
ISEmisc .md/.txt/.text/.json attachment content, plus filename/topic subject for those and for a wide range of code/config attachment types (.py, .php, .js, .sh, .sql, .html, .css, .c, .cpp, .java, .rb, .go, .rs, .pl, .xml, .yml/.yaml, .ini, .conf) — those code/config types are filename/type searchable only, not full-text searched, but always viewable via "Open file". The owning forum post, plus "Open file" to download/view the attachment directly.
ISEmega Runs your query against ISE + ISEpdf + ISEmisc only and merges the three result lists into one page (interlaced by relevance score by default, or a flat chronological merge under /sort newest/oldest). Shows up to 180 results by default (soft cap — an on-page "Show all" link or an explicit --limit/&all=1 bypasses it); everything was still searched and ranked, the cap only limits how many cards are drawn. Whichever of the matching post / PDF viewer / attachment the result actually is — same links as that source's own search.
ISEmedia Images and videos, by meaning and by keyword — not by any of the above. Your query text is compared against every indexed image/video using an AI vision model (CLIP), so it can find visually-relevant results even when a caption doesn't use your exact words. As of v1.2.0, a real search term must ALSO literally appear in the item's caption, filename, or the post subject it was attached to — so a query only returns items that are both visually similar AND textually confirmed, not just "looks related" on CLIP's judgment alone. Not included in ISEmega — this is a separate dropdown option, searched on its own. No quoting or wildcard support (see the note above and the ISEmedia section below). The image displayed inline / video attachment, plus a "Jump to post" link.

ISEmedia — how it's different

ISEmedia doesn't use a word index the way the other four sources do — every search starts by encoding your query text with the same AI vision model (CLIP) used to encode every stored image/video, then ranking everything by how visually/semantically close your query is to each item. On its own, that kind of match can surface a genuinely relevant image whose caption never uses your exact words — the whole point of a meaning-based search — but it can also rank something that merely "looks similar" above an item that's a real, obvious keyword match. As of v1.2.0, ISEmedia requires a literal match on the item's caption, filename, or its post's subject line before that item is shown at all for a query with real search terms — CLIP similarity then decides the order among those keyword-confirmed matches, it no longer decides who gets in.

This means: no quoting ("phrase" isn't a concept here), no wildcards (*/? aren't recognized), and a bare /sort newest/oldest with no other search term behaves like it does everywhere else — nothing to gate by, every item's a candidate, sorted purely by upload date.

Type /help in any of the five search boxes to get back here.