Sorry for the spam open/close. Let me know if I you guys are interested in this and I can reopen it.

Generally speaking, probably yes, but I personally haven't gotten a chance yet to look at it. Currently every member of the terminal team is unfortunately either working on another project or on sick leave, hence the overall delays since late last year. One of the things @zadjii-msft made was released just recently: https://learn.microsoft.com/en-us/windows/powertoys/command-palette/overview
The project I'm working on will be released soon as well.

I plan to review this PR after I fixed the remaining major issues the the Preview/Canary version has. (Which is what has occupied what little time I had for Windows Terminal since then.)

Sorry, didn't mean to rush you, was more worried I was spamming you guys with all of these fuzzy finding PRs. Please let me know if it doesn't make sense for what ever reason and I can close it.

I'm also somewhat confused by the code's dissimilarity with the original fzf to be honest (that's not an issue in on itself; it just surprised me).

I think there are a couple of things that contributed this.

• The original telescope-native port that I ported was done back in 2022 before the delimiter class type etc, and I think he had removed some stuff like the normalization.
• When I ported it to c++ I mangled all of the variable names trying to understand how all of the dynamic programming and back tracking work.

Should I try to update use the latest fzf logic?

That aside, for the upcoming project that I've worked on, I ported VS Code's fuzzy matcher to Rust. Here's the original: https://github.com/microsoft/vscode/blob/071eafaf5ab4de3814466b616fe00a66d2739ad2/src/vs/base/common/fuzzyScorer.ts If you'd like I could generate a C++ port of it next week based on my Rust version. The benefit of that code is that it's a lot simpler. The disadvantage is that fzf is a leagues better algorithm and if we had it, it would definitely be superior of course. I guess it's a trade-off.

Totally understand if the VS Code algo is more maintainable etc, let me know what direction you guys want to go. I am happy to try to port the typescript or the rust code or incorporate your port of the rust code.

The other thing that I am worried about is that I still haven't figured out how to run LocalTests_TerminalApp which will probably have some failures from the new algo.

Oh, right, I forgot your question. First you need to build these two projects:

Then you do this in PowerShell:

Import-Module .\tools\OpenConsole.psm1
Invoke-OpenConsoleTests -Test localTerminalApp

For me this currently fails in 18 tests, but only 3 of those are due to your PR. We're not doing a great job of maintaining these tests unfortunately. You can tell it to only run your relevant tests like this:

Invoke-OpenConsoleTests -Test localTerminalApp -TaefArgs /name:TerminalAppLocalTests::FilteredCommandTests::*

Edit: I fixed them.

That worked, I am able to run them locally now. Thank you!!

What I'm missing mostly is some Unicode normalization like fzf has: https://github.com/junegunn/fzf/blob/master/src/algo/normalize.go
This could be part of https://github.com/microsoft/edit/tree/main/tools/grapheme-table-gen in the future so we can generate a small trie for the mapping.

This may be way beyond my understanding of unicode. Would that be adding something like this (from the fzf port you had done)?

    // Normalize rune using ICU NFD and removing combining marks (Mn)
    // This aims to replicate the Go version's accent removal.
    UChar32 normalizeRune(const UChar32 c)
    {
        if (isAscii(c))
        {
            return c;
        }

        static const auto norm = []() {
            UErrorCode status = U_ZERO_ERROR;
            return unorm2_getNFDInstance(&status);
        }();
        if (!norm)
        {
            return c;
        }

        UChar decomp[8];
        UErrorCode status = U_ZERO_ERROR;
        const auto len = unorm2_getDecomposition(norm, c, &decomp[0], ARRAYSIZE(decomp), &status);
        if (U_FAILURE(status) || len <= 0 || !isAscii(decomp[0]))
        {
            return c;
        }

        return decomp[0];
    }

Yes, although I'm not entirely sure if that would be fast enough and whether it's really the same thing that fzf does. That's something we'd have to experiment with over time.

/azp run

/azp run

/azp run

/azp run

@e82eric certainly appreciates us duking it out on his PR. 😁

/azp run

Just catching up on this, sorry about this! Guessing I should have been running the x86 build locally to catch that?

Wohoo it merged!

Yes, that type of failure only comes up in the x86 build. But it's fine - you already did way enough for us. 🙂 (I hope I didn't make a mistake with the size_t conversion!)

Perhaps the most annoying thing is that you can't actually run the x86 build. It just... builds or it doesn't. Nobody tests it on Windows 11. It isn't compatible with the console kernel driver.

Thank you so much @e82eric for literally everything. Seriously.