Forward fish_key_bindings for fish 4.3 changes (AI assisted)

[scaryrawr]

AI disclosure: This change was made with copilot 😅 after noticing the issue when updating to fish 4.3.1.

Fixes the regression with falling through to vi mode in default mode for fish 4.3.0.

Description

In fish 4.3.0:

fish no longer sets universal variables by default, which simplifies configuration. Specifically, the fish_color_, fish_pager_color_ and fish_key_bindings variables are now set in the global scope by default. After upgrading to 4.3.0, fish will (once and never again) migrate these universals to globals set at startup in the ~/.config/fish/conf.d/fish_frozen_theme.fish and ~/.config/fish/conf.d/fish_frozen_key_bindings.fish files. We suggest that you delete those files and set your theme in ~/.config/fish/config.fish.

This change forwards the fish_keybindings for the prompt as well as does a check if the fish_keybindings is not set.

Motivation and Context

In default mode, we are getting < instead of > for the prompt arrow since it falls through into the vim mode checks.

Screenshots (if appropriate)

How Has This Been Tested

• I have tested using Linux.
• I have tested using MacOS.

Checklist

• I am ready to update the wiki accordingly.
• I have updated the tests accordingly.

[tsacha]

Human here. Thanks for the patch :D

[peanball]

fixes #620, #622 for me

[nextzhou]

Thanks for this fix! This PR provides a comprehensive solution for the prompt character issue.

I can confirm this addresses #632 as well (same root cause - fish_key_bindings not being passed to background processes).

This PR is more complete than #626 since it fixes both:

1. Variable passing to background processes
2. Empty value handling for Fish 4.3+

Would be great to see this merged soon as it's affecting quite a few users! 🙏

[grahamannett]

anyway for this to get merged so others dont have to fisher install scaryrawr/tide@fix-keybind?

[mzilinski]

+1 on this fix — I independently hit the exact same bug and opened #653 before finding this PR (now closed as duplicate). Worth noting that the root cause isn't limited to fish 4.3: any setup that stores fish_key_bindings as a global (rather than universal) variable triggers it, because the async prompt subshell doesn't inherit globals.

Additional reproduction (independent of fish 4.3)

On CachyOS (which ships a fish config that sets fish_key_bindings globally via config.fish), the prompt shows ╰─❮ instead of ╰─❯ even on fish 4.2 and with default emacs bindings.

Confirming the root cause

What made it obvious is that calling the character function directly in the interactive shell prints the correct glyph:

$ echo $fish_key_bindings
fish_default_key_bindings
$ echo $fish_bind_mode
default
$ set _tide_status 0; _tide_item_character
 ❯

…while the actual prompt still renders ❮. That proves the discrepancy is between the interactive shell and the background subshell — exactly what this PR fixes by forwarding fish_key_bindings alongside fish_bind_mode.

The added test -z "$fish_key_bindings" guard in _tide_item_character is a nice belt-and-suspenders: it also fixes any future code path where the variable might be legitimately empty.

Would love to see this merged — it's a subtle but very visible bug.