dodexahedron

Ok, so... With that restriction, what constitutes a match only has to satisfy the following conditions: - Must be specifier character immediately followed by a valid hotkey - Valid specifiers...

Also I think the behavior should be modified so that, if the HotKey property is already set (ie not KeyCode.Null), none of this even runs, so that explicitly setting the...

Coolio. All that stuff should be pretty easy to do, then. As I mentioned, I had started that branch off intending to just do opportunistic performance stuff for TextFormatter. But,...

One thing is we repeat a bunch of operations quite a bit. So I'm trying to unwind some of that in TextFormatter and avoid at least some of that duplication...

Actually... At least to avoid one source of potential conflicts... I'm going to cherry pick a few commits from what I've done so far that aren't breaking changes but are...

There we go. #3282 That PR is a pretty minimal set of changes and some are also things that I myself have done multiple times but that somehow kept not...

Renamed this to reflect the expanded scope better.

#3287 is relevant to this, but posted as a separate issue for visibility, since it's a pretty core type. That's being dealt with in this work.

Hey @tig @BDisp TextFormatter.FindHotKey has a bool parameter to enable old behavior of using first capital letter instead of the character following a hotkey specifier. Do we want that or...

About that... As it turns out, nothing internal to the library actually even uses it explicitly except for RadioGroup, which passes true unconditionally, which looks like old behavior that's almost...