.NETpad 2025: Tab Navigation (Premium)

I'd like to reach a certain level of quality before I post the pre-release code for the tabs-based version of .NETpad to GitHub. This is proving elusive, but we've all been told that the final 20 percent of any project is often the most difficult. Or as I think of it, this is when my procrastination comes back to haunt me.

Maybe that's not fair: I did spend a lot of time on what I still think is the most difficult technical challenge--literally managing multiple documents and tabs--and I feel it's understandable that that work would take a bit of time. But once that was largely one, I had to start addressing a lot of related issues, fit and finish issues. Some of that was backend modularization work, while others were tied to the UI, like maintaining the text insertion cursor location and selected text for each document/tab.

I could easily get bogged down by this work, since it seems like it never ends. And each time I make a step forward, I always seem to come up with something new, some new issue to solve. I know I need to let go at some point and just make the code public, but I also want the app to meet some minimum requirements for functionality and quality.

Here's one example. My tabs-based version of .NETpad needs to support keyboard-based navigation, where typing Ctrl + Tab will display the next available/visible tab and its associated document. (Typing Ctrl + Shift + Tab should likewise navigate backward through the available/visible tabs.)
Keyboard navigation: First steps
I had this idea in the back of my head that tab navigation was somehow tied to the Z-index order of controls in the app, but when it came time to finally address this issue, I realized how ill-formed this notion was. Instead, what I'd need to do was specifically address the relevant keyboard shortcuts and then change the focus to the appropriate tab and its associated document.

This is easier said than done.

Part of the problem here is that I had to (once again) work around some limitations in WPF's implementation of tabs, which involves the TabControl and TabItem controls. Without getting into the explanation for this again, what I found is that it's best to hide TabItems that are closed by the user rather than literally killing them. And because of that, a lot of the tab management code I've written involves checks to see whether whatever TabItem(s) are visible, meaning "open" (and thus available), and which are hidden (meaning "closed" and thus unavailable). So, starting with the simpler Ctrl + Tab case, I would need to select/display the "next" tab each time the user typed that keyboard shortcut.

This felt doable. Yes, I remain that naive.

Without yet worrying about what happens when you're viewing the last visible/open tab--in which case, it should go back to the first visible open/tab--what I came up at first with seems simple enough. The idea here is to step through all the TabItems starting with the current TabItem, determine which...