Incremental means if you search "test" and then search "a", the search will find "testa" if the current search term's next letter is a, as opposed to non-incremental where it searches from the end of the current search term. This is typing in vscode's find widget (incremental) vs pressing enter (non-incremental).

So it's broken in master branch?
Steps:

• search jeanp
• press enter to select the second match
• type i so the search term is jeanpi
• it selects the last match
  • I expect the selection to still be the second match and just expand it (this is the behavior I see in the vscode editor find widget), is this how it should work?

Yes it does seem to be broken, incremental should not jump to the result at the bottom

I fixed the incremental code but the flag is redundant

• it will always be incremental if there's a selection in the terminal (which I like as it behaves as the vscode editor), with this I only needed to fix 1 test
• if I make the flag required, around 6 test will fail

Pressing shift, ctrl or alt will do a non-incremental search

Are you referring to this ?, as I mentioned the incremental flag does not have any effect now (it can be removed in a separate PR), if there's a selection in the terminal then search will be incremental, but I also found a bug I fixed in the last commit and added a test, so maybe that was it

Doing an incremental search will not apply the white activeMatchBorder defined here

It's a bug in the decorations rendering, it does not take into account if it's on the top or bottom layer so it could happen that a decoration in top layer renders below, PR fixing it #4516

I mean this, I'm pressing only shift, ctrl and alt in the gif. It's moving the active match but should do nothing:

I thinks that's an issue with the dom events used in the demo, it's always using keyup for everything and always fire a seach, vscode search widget uses input to detect the actual input changed and also onKeyDown to handle special cases like enter, up/down arrow, tab, etc here