Feat/search in messages in session

[OpeOginni]

Feature corresponding to #4714

Enables searching for text using the keybind ctrl + f, changes prompt input to a search input that then highlights any matches in the session.

Users can return back to the prompt bar by clicking esc

Users can navigate matches using the up and down key.

Idea and flow was my idea, but did use AI for some of the implementation, also for searching codebase where other functions were used such as scrolling programmatically.

further-reduced.mov

[OpeOginni]

Its a bit of string manipulation to get the markdown highlighting working, and also had to make use of the strikethrough syntax and change that to highlight, since the parses doesn't support using == for highlighting markdown. So might consider this a rough fix. Would like to know what anyone thinks

[ariane-emory]

This only seems to be half-working. Study the following screenshots: the viewport remained in the same position as I incremented it from 1 of 12 to 6 of 12, only actually repositioning to the next search result after it had been incremented to 7 of 12.

[OpeOginni]

@ariane-emory yeah that's because they are all in the same message block I'm guessing, since the only unique part of the component we can reference to scroll to is the message in which the word appears in, yeah it's not the best.

Best thing to do is to get more ids for parts of text in a complete message block.

PS: Happy to see you using it 🙂

[ariane-emory]

Sorry, I may not be following. What are 'all in the same message block'? While incrementing from 1 to 6, only a single instance of the search term is onscreen.

[OpeOginni]

Ohh really, must have missunderstood then, so it shows 12, but you only see 2? Or you do see more if you scoll down but for example they all are in the same response block from either you or the model?

[ariane-emory]

There are 12 instances present total, but moving to the next search item doesn't necessarily put the item on screen: there are 6 instances of the string insta in the first message, but it is a multiple-screen long message: instances 2 through 6 all occur at least 1 screen into the message.

Since the viewport remains pointed at the start of this long message, the these instances enter the viewport while incrementing the search's instance index, so I won't actually ever actually see those instances unless I manually scroll within the message. This isn't the behaviour users generally expect from a search function.

[OpeOginni]

Yes I understand now, it goes with what I was saying in the other message

@ariane-emory yeah that's because they are all in the same message block I'm guessing, since the only unique part of the component we can reference to scroll to is the message in which the word appears in, yeah it's not the best.

Best thing to do is to get more ids for parts of text in a complete message block.

PS: Happy to see you using it 🙂

For now each match is connected to a message block, so we dont update the viewport until its a different message, I could tinker a bit more to find a solution.

[ariane-emory]

@OpeOginni Your explanation for why it behaves this way does make sense, but it nonetheless does seem to violate the expectations users are likely to have: when a user selects item 2 of 12 in a search tool, they likely expect the second instance of the needle to at least be displayed somewhere on the screen.

Eager to see what solution you come up with, I'd love to have a search tool with the same usual, conventional behaviour as most other applications' search tools.

[OpeOginni]

I see there is a need for it, ill surely get it done!

[OpeOginni]

@ariane-emory Made an update, mostly using estimation based on the index of the word, to predict its position and determine if it is in view or not. Did some tests to the best way I can, its getting about 80% scrolls right.

Try it out and tell me how it goes?

[ariane-emory]

@OpeOginni Sure, will do - it's already late, so I might not get to try it out tonight, but if I don't I'll certainly try it out tomorrow.