Summary

XF86 multimedia keysyms (XF86New, XF86Save, XF86Open, etc.) are mapped to key names like "New", "Save", "Open" on the Linux platform layer. When Zed
picks the highest-precedence binding to display in menus and keybinding hints, it can select these XF86 bindings over useful ones like Ctrl+N, resulting in confusing labels "New" as a shortcut looks like the UI is broken, not like a keybinding.

What changed

• Added is_xf86_key() in keystroke.rs to identify XF86 multimedia key names (new, open, save, cut, copy, paste).
• Added has_xf86_keystroke() on KeyBinding to check if any keystroke in a binding is an XF86 key.
• Filtered XF86 bindings out of highest_precedence_binding_for_action in key_dispatch.rs — this is the method used by menus and keybinding hints to decide what to display.
• Added two unit tests covering both the filtering and dispatch behavior.

Impact

• Menus and keybinding hints no longer show XF86 key names. They fall through to the next non-XF86 binding (e.g. Ctrl+N) or show nothing if no
  alternative exists.
• Key dispatch is untouched — if a user actually presses an XF86 key, it still triggers the bound action.
• bindings_for_action (the full list, used by the keymap editor) still includes XF86 bindings.

Trade-offs

• Users with rare XF86 keyboards will no longer see those bindings in menus, so they can't discover them through the UI. This is acceptable because:
  (1) these keyboards are essentially extinct, (2) the keys still work when pressed, and (3) the bindings are still visible in the keymap settings.
• The is_xf86_key check uses a hardcoded list of key names. If new XF86 keysyms are added to the platform layer in the future, the list would need to
  be updated. An alternative would be tagging keystrokes as XF86 at the platform layer, but that's a larger refactor for minimal gain.

Open to recommendations about that.

@Dnreikronos Instead of doing this, can we re-order the keymap file to acheieve the same effect - that must be what we do with other cases where there are multiple bindings for one action.

@Dnreikronos Instead of doing this, can we re-order the keymap file to acheieve the same effect - that must be what we do with other cases where there are multiple bindings for one action.

Thanks a lot!
I was id doubt about how to do that the best way as possible!!

@Dnreikronos Instead of doing this, can we re-order the keymap file to acheieve the same effect - that must be what we do with other cases where there are multiple bindings for one action.

Hi @ConradIrwin!
Can you analyze the changes again, please?

Looks good! I don't think we need those tests.

Are there other keys except save that need moving?

Looks good! I don't think we need those tests.

Are there other keys except save that need moving?

No, save in ContextEditor was the only one in the wrong order. Back when the XF86 keys were first added (a22d8ef), they all went after the regular bindings. But aacd80e ("Prefer later bindings in keymap section for display in UI") reordered everything on the same day, it just missed this one spot in ContextEditor.

I also removed the two tests as you suggested!

Thanks! And glad it ended up being a simple fix.