Feature request: searchable Work Orders

[TimurKelman]

Search functionality is in so many other views, but unfortunately is missing from Work Orders.

[lethosor]

The main reason this one is trickier to implement properly is because the screen doesn't actually maintain its own list of manager orders - they are only stored in world.manager_orders. The screen just maintains its cursor position, mode, etc.

There are some other search implementations that search over global data that isn't part of the current screen (e.g. the k search, aka look_menu_search), so it's possible, but tricky to do right in this case because the data persists well beyond the lifetime of the screen (in contrast, the data used by the k view, while global, is only really valid for a short duration). It's further complicated by the fact that orders can refer to each other, so if you filter out a dependency of another order and open it with Enter, you would get something that looks like this:

There should be an order name above "must". There might be other cases where DF crashes due to entries being removed (even temporarily) from world.manager_orders to enable searching.

Short version: it might be possible, but it's more complicated to do safely.

[ab9rf]

At a minimum, you'd have to ensure to not remove any order that is dependent on the orders that match the search.

Also, you'd have to restore the full list when you go into the detail screen because the user might choose to create an order dependency while in the detail screen, and that needs the full list available. This may cause problems since the detail screen uses an index into the global order list. I suppose you could restore the full list only if the user asks to create a order dependency, but... ugh.

[myk002]

an alternative might be to just highlight orders that match a search, and provide a hotkey (or override the behavior of the arrow keys) to jump the cursor to the next highlighted match. this would be a different look-and-feel from the other search interfaces, but it would avoid all the rather scary pitfalls of dynamically modifying the global list. the new behavior won't be completely foreign, though, since almost all text searches work this way in other applications.

widgets:

• search text
• index of current selected match and total number of matches, e.g. "3 / 15"
• hotkey labels: <key>: next match <key>: prev match

we might want to keep the standard behavior for the arrow keys and pgup/pgdn so players can still interact with unmatched orders. maybe next/prev match could be shift up/shift down or left/right.