How are you using this? Is the intent to be able to write keyboard-interface that don’t rely on the native KeysDown[] order?

I think we ought to populate this list properly and I’d perhaps even consider removing the mapping step at all.

Yes, the intent is to use other hot-keys or keys beyond A,C,V,X,Y,Z that are currently provided -- any other alpha or numeric keys, function keys, and so on.

I have been previously copying-and-pasting over the ImGuiKey_ enum to add more, but I did not find this a tenable solution as I continue to download and merge new versions of ImGui.

Well my initial intention was to keep it coherent across the entire ImGui namespace, even in my own widgets which extend the ImGui namespace and require additional keys. But you're right that if I'm only implementing the additional enums in my own widgets that are declared in files outside of the imgui base, it doesn't really matter anyway.

At the very least it could be a soft-bridge between populating the list entirely (or at least with a full alpha-numeric list), or removing it entirely.

Thanks for the clarification.

I want to populate this list but will probably bundle that change when I have a better understanding of how we are going to handle shortcuts and keyboard internationalization (under various frameworks it is not easy to retrieve characters when e.g. a CTRL modifier key is held, requiring us to rely on keys instead of characters, but those are often derived from non-localized scan codes).

I have been previously copying-and-pasting over the ImGuiKey_ enum to add more, but I did not find this a tenable solution as I continue to download and merge new versions of ImGui.

In the meanwhile, may I suggest you use the strategy proposed in your PR and you only have to merge in the 2 lines (#ifndef and #endif) in imgui.h for now? You can apply a patch automatically post update if you don't want to be git merging.

Closing this as I think we'll more probably aim straight for something like #2625