Now that almost all actions can be triggered from outside the context
menu and are available for more than one item type, it's easier to check
for available actions dynamically.
... but don't trigger search if the key closes the editor.
Also get rid of the on_click of the saved searches root which has
already been removed on main.
... in favour of in-line editing. This is simpler and more ergonomic for
the user (and the programmer) but doesn't allow for editing parents
through text input (in the case of tags and decks).
Thus, disable renaming, deleting etc. for the current deck item.
As a consequence, editable is no longer needed as a field of SidebarItem
as it can be derived from its type.
- SearchTerm -> SearchNode
- Operator -> Joiner; share between messages
- build_search_string() supports specifying AND/OR as a convenience
- group_searches() makes it easier to negate
While implementing the overdue search, I realised it would be nice to
be able to construct a search string with OR and NOT searches without
having to construct each part individually with build_search_string().
Changes:
- Extends SearchTerm to support a text search, which will be parsed
by the backend. This allows us to do things like wrap text in a group
or NOT node.
- Because SearchTerm->Node conversion can now fail with a parsing error,
it's switched over to TryFrom
- Switch concatenate_searches and replace_search_term to use SearchTerms,
so that they too don't require separate string building steps.
- Remove the unused normalize_search()
- Remove negate_search, as this is now an operation on a Node, and
users can wrap their search in SearchTerm(negated=...)
- Remove the match_any and negate args from build_search_string
Having done all this work, I've just realised that perhaps the original
JSON idea was more feasible than I first thought - if we wrote it out
to a string and re-parsed it, we would be able to leverage the existing
checks that occur at parsing stage.
