Implement search filter that can be cycled through

[Davejkane]

Goal

As discussed in the thread here, we'd like a path search, that acts as a filter on the currently loaded paths. It should then be able to cycle through this subset of paths, forward with n and backward with N.

Implementation

• As with #40 we're going to want to take a string here, by entering a text entry mode.
• On an Enter or Return keypress we will perform a filter on the images path vector.
• The filter should be a simple check if the stringified path contains the search text. I don't think we need anything fancy like fuzzy search here.
• The filter should probably return a Vec<usize>, holding the indices of the matched paths. This would allow regular operations like increment and decrement to continue and n and N to still be valid even after other intermediate actions have been performed.
• After the filter has been returned, we should render the next hit, NOT the first.
• Any operations that mutate the images path vector, such as move or delete should either cause the Vec<usize> to be rebuilt, or perhaps invalidated. I'm leaning towards rebuilt. But this should not cause us to jump to the next search hit.

Important

This should either be implemented AFTER #40 or by the same developer.

[NickHackman]

I'll happily take this one!

I think we should use a regex for searching just because it's nice to have. Oh, furthermore wrapping like vim (when you hit the bottom it goes back to the top). Your feature set looks great!

[gurgalex]

@NickHackman All yours.

Thanks for the continued contributions. We look forward to turning this into a suitable image viewer (and minor management) replacement.

[Davejkane]

@NickHackman I like the regex idea. Perhaps if the string is just text, we could append * to the start and end of the string and build the regex. I'd still like this program to have good international support, so we don't just want ascii matching here when determining if the string is just text. So probably just want to check whether or not the string contains symbols.

If the string is not just ascii, then we may need to perform unicode normalization on the string. I have no idea if Paths are in any way unicode normalized. We may want to normalize the paths when we first build the vector, and normalize the search string. That way we can compare apples with apples.

This might seem like overkill, but this could be an opportunity for our software to have better international support than the alternatives and differentiate ourselves. The tech world isn't ascii any more, and luckily we're using Rust, which is in a much better position to solve these challenges than C was.

Some links. https://en.wikipedia.org/wiki/Unicode_equivalence https://github.com/unicode-rs/unicode-normalization

[gurgalex]

Hi @NickHackman

Do you plan to work on this M-F next week?

If not, I can start working on it.

[NickHackman]

@gurgalex go ahead, classes are ramping up and midterm week has come around. sorry that I've been dark for so long. I'll contribute more in the future, but after midterm week settles down.

[gurgalex]

@NickHackman Not a problem. I forgot that summer classes are much more intense than full semester classes.

Just wanting to make sure we weren't going to duplicate effort needlessly.

Sidenote: Is https://github.com/NickHackman/Aurr a school project, or is it open to contributions from anybody?

[NickHackman]

@gurgalex Open source, going for an AurHelper that handles all the bases, but doesn't try to take over for Pacman. Or at least that's the idea, we're really early in, so it's mostly up in the air. Right now it's just a library...

[gurgalex]

@Davejkane Some clarification on a point.

After the filter has been returned, we should render the next hit, NOT the first.

Is this saying that if we have the following filenames

9 11 12 13 14

with a filter of *1* (any path with a 1 somewhere in it)

The next hit (image) shown should be 12?

[Davejkane]

@gurgalex it depends what image you are currently viewing. For example, just say there's 20 images, and you are viewing image with index 5. And your filter returns images 4, 7 & 10. You should show image 7 in this case, not image 4, which would be the "first" in the list. I hope that clarifies.

[gurgalex]

@Davejkane Yep, thanks for the clarification.

2 11 12 13 14 (search filter *1*) User is at image 12

The filter should show image 12 with infobar text image 2 of 4 (some other stuff/color to indicate search feature) It should not start at the first result for the search.

[Davejkane]

@gurgalex exactly. I'm excited about this feature and super happy you're working on it.

[gurgalex]

Yep, taking care of #89 first, as I'm unsure how much impact multithreading (and progress indicators) will have on the codebase.

Still working on this though. Progress indicators seem nice to have for the search filter as well.