Open romanofski opened 6 years ago
Just realising that it doesn't just need a new action, but also an editor which accepts input from the user. The substring is the needle we then try to find in the haystack.
I was eyeing this one for quite a while, since it would also help for the file browser to quickly find the files from the list of files. I guess we do want to provide a quick way of searching through potentially large number of items which dismisses any use of simple searches. I was looking into building perhaps a substring index to make this functionality to perform quickly. Perhaps not exactly at the same time when the result of a search is loaded into a vector, but rather as a separate thread to build e.g. a suffix tree which can be utilized. Have you spend any thoughts on this one?
We talked about this and defer it for now. Reason being is that we want to make manipulating the search using notmuch more user friendly and with that, this feature might not be needed.
We need a search feature to select the next matching list item. This is a) important if a list has a lot of entries and you want to jump to an item with a known name and b) important to write more reliable tests. Typically this is bound to
/
. We already have a similar action implemented calledselectNextUnread
. All what needs to happen here is to make this action applicable to modes which show lists. That is:Perhaps it would make sense to create a
Searchable
class in order to limit to which modes this action is applicable and makes sense?