Color Filters: Logical Operators & Path Scoping Behaving Inconsistently — Can Anyone Reproduce?
Posted: 01 Apr 2026 01:20
Hi all,
I’ve been working on a visual governance structure using Color Filters, and I’ve run into several behaviors that don’t seem to match the documented syntax. Before assuming these are bugs, I’d like to ask the community whether others can reproduce the same results.
I want to emphasize up front:
**Color Filters are one of XYplorer’s most powerful features**, and the ability to visually organize complex folder structures is a major advantage of the program. That’s exactly why I’m trying to understand whether the issues below are limitations, quirks, or something that needs clarification.
---
# **1. `OR` expressions match only some prefixes**
Example:
```
type:folder AND (name:1* OR name:2* OR name:3* OR name:4* OR name:5* OR name:6* OR name:7*)
```
Expected:
All folders beginning with 1–7 should match.
Actual:
Only some prefixes match. Changing rule order or adding/removing unrelated rules changes which prefixes match, even though the rule itself is unchanged.
---
# **2. `NOT` expressions either match nothing or apply globally**
Example:
```
NOT (name:1* OR name:2* OR name:3* OR name:4* OR name:5* OR name:6* OR name:7*)
```
Expected:
Match everything except items beginning with 1–7.
Actual:
- Sometimes matches nothing
- Sometimes applies globally across the entire system
- Behavior changes depending on rule order
---
# **3. `path:` and `prop:#path` do NOT scope Color Filters**
This is the most surprising part.
Example:
```
path:*OneDrive - Veterans Service Club at Los Prados* AND NOT (name:1* OR name:2* OR name:3* OR name:4* OR name:5* OR name:6* OR name:7*)
```
Expected:
Only apply inside that path.
Actual:
The rule applies to folders **outside** that path — but only those beginning with certain digits (2–6).
This suggests the path condition is being ignored or evaluated inconsistently.
I can reproduce this repeatedly.
---
# **4. Parentheses do not reliably group logic**
Expressions like:
```
(attr:d AND name:1*) OR (attr:d AND name:2*)
```
or
```
path:*Folder* AND NOT (name:1* OR name:2*)
```
produce different results depending on rule order and unrelated rules.
---
# **5. Color Filters behave differently from Search / Scripting**
The syntax looks identical, but the behavior is not.
Search and scripting handle AND/OR/NOT/path as expected.
Color Filters do not.
---
# **Why I’m posting this**
I’m not asking for a fix — I understand XYplorer is a one‑man project and development time is limited.
I *am* hoping to:
- confirm whether others see the same behavior
- understand whether these are known limitations
- learn whether there is a recommended pattern for reliable Color Filter logic
- help document the actual behavior for future users
Color Filters are a standout feature of XYplorer, and understanding their real boundaries would help users get the most out of them.
If anyone can reproduce even one of the examples above, that would be extremely helpful.
Thanks in advance to anyone who can test or comment.
---Bill
I’ve been working on a visual governance structure using Color Filters, and I’ve run into several behaviors that don’t seem to match the documented syntax. Before assuming these are bugs, I’d like to ask the community whether others can reproduce the same results.
I want to emphasize up front:
**Color Filters are one of XYplorer’s most powerful features**, and the ability to visually organize complex folder structures is a major advantage of the program. That’s exactly why I’m trying to understand whether the issues below are limitations, quirks, or something that needs clarification.
---
# **1. `OR` expressions match only some prefixes**
Example:
```
type:folder AND (name:1* OR name:2* OR name:3* OR name:4* OR name:5* OR name:6* OR name:7*)
```
Expected:
All folders beginning with 1–7 should match.
Actual:
Only some prefixes match. Changing rule order or adding/removing unrelated rules changes which prefixes match, even though the rule itself is unchanged.
---
# **2. `NOT` expressions either match nothing or apply globally**
Example:
```
NOT (name:1* OR name:2* OR name:3* OR name:4* OR name:5* OR name:6* OR name:7*)
```
Expected:
Match everything except items beginning with 1–7.
Actual:
- Sometimes matches nothing
- Sometimes applies globally across the entire system
- Behavior changes depending on rule order
---
# **3. `path:` and `prop:#path` do NOT scope Color Filters**
This is the most surprising part.
Example:
```
path:*OneDrive - Veterans Service Club at Los Prados* AND NOT (name:1* OR name:2* OR name:3* OR name:4* OR name:5* OR name:6* OR name:7*)
```
Expected:
Only apply inside that path.
Actual:
The rule applies to folders **outside** that path — but only those beginning with certain digits (2–6).
This suggests the path condition is being ignored or evaluated inconsistently.
I can reproduce this repeatedly.
---
# **4. Parentheses do not reliably group logic**
Expressions like:
```
(attr:d AND name:1*) OR (attr:d AND name:2*)
```
or
```
path:*Folder* AND NOT (name:1* OR name:2*)
```
produce different results depending on rule order and unrelated rules.
---
# **5. Color Filters behave differently from Search / Scripting**
The syntax looks identical, but the behavior is not.
Search and scripting handle AND/OR/NOT/path as expected.
Color Filters do not.
---
# **Why I’m posting this**
I’m not asking for a fix — I understand XYplorer is a one‑man project and development time is limited.
I *am* hoping to:
- confirm whether others see the same behavior
- understand whether these are known limitations
- learn whether there is a recommended pattern for reliable Color Filter logic
- help document the actual behavior for future users
Color Filters are a standout feature of XYplorer, and understanding their real boundaries would help users get the most out of them.
If anyone can reproduce even one of the examples above, that would be extremely helpful.
Thanks in advance to anyone who can test or comment.
---Bill
Please include the following information: