Checklist
Describe the feature request
I wanted to run a search query "user != root" or "state != sleeping" but apparently "!=" or "!" operators aren't supported.
Digging into the code to find where to add, I found more improvements are possible.
Better Filter syntax
The search can be made in 3 modes
- Literal mode: activated when user types a plain string without operators or quoted string ( with escapes )
Action: whatever is typed is matched against Name. Equivalent to double-quoting the text.
- Regex mode: activated when Regex(Alt+W) is set, OR when user wraps the query in
/query/. Latter can support flags like i too.
Action: whatever is typed is parsed as regex and matched against Name.
- Query mode: activated when Regex(Alt+W) is unset and user types an operator.
Action: Executes query as a boolean expression, where:
- Value can be literal (
"quoted", 'quoted' or numbers ), regexp: ( /value/ ) or more shorthands for time, bytes, percentages, etc.
- operators
!= (not equal), ! (not), ~ (partial match) and current ones are supported. We can also support more operators like in or like operators from sql, but having regexp is enough I guess.
Looking for feedback on the design before I try an implementation.
I think this will improve the parser too, making it a proper expression parser.
Checklist
Describe the feature request
I wanted to run a search query "user != root" or "state != sleeping" but apparently "!=" or "!" operators aren't supported.
Digging into the code to find where to add, I found more improvements are possible.
Better Filter syntax
The search can be made in 3 modes
Action: whatever is typed is matched against
Name. Equivalent to double-quoting the text./query/. Latter can support flags likeitoo.Action: whatever is typed is parsed as regex and matched against
Name.Action: Executes query as a boolean expression, where:
"quoted",'quoted'or numbers ), regexp: (/value/) or more shorthands for time, bytes, percentages, etc.!=(not equal),!(not),~(partial match) and current ones are supported. We can also support more operators likeinorlikeoperators from sql, but having regexp is enough I guess.Looking for feedback on the design before I try an implementation.
I think this will improve the parser too, making it a proper expression parser.