$fish_escape_delay_ms not working as a universal variable

[InspectorMustache]

I have fish_escape_delay_ms set to 10 as a universal variable. However, after upgrading to Fish 2.6.0, it seems that setting isn't honored anymore. echo $fish_escape_delay_ms still gives me 10 but the delay is noticeably longer. If I enter set fish_escape_delay_ms for each new shell instance it works fine.

I'm on ArchLinux (4.11.7) using Fish with Termite.

[krader1961]

I don't think setting it as a uvar ever worked but it should. The fix is trivial: call update_wait_on_escape_ms() from misc_init() so it is honored at startup.

[InspectorMustache]

Hmmm… no idea, why I'm only seeing this issue with 2.6 then. Anyway, thank you very much for putting this in 2.7.0. In the meantime, it should be very easy to work around.

[krader1961]

Turns out that this did work prior to commit 6d02bec. That change included suppressing reacting to variable changes until the environment subsystem was initialized. I'll need to ponder how to get the react_to_variable_change() function to run when loading uvars.

[krader1961]

This change in behavior is because prior to commit 6d02bec what was then called the input_init() function (now named init_input()) was called as a side-effect of actually reading commands to run. That is, after 99% of the fish initialization logic had run. That function called input_common_init() which explicitly calls update_wait_on_escape_ms(). All of that happened after the universal variables had been loaded because it was executed lazily rather then explicitly. In other words, too much spooky action at a distance behavior that wasn't obvious when commit 6d02bec was merged was the reason this used to work.

The post commit 6d02bec code explicitly initializes the input subsystem as part of initializing the run-time environment before the uvars are loaded. So the the reason this magic uvar doesn't have any effect is because input_common_init() is no longer run after uvars are loaded.

Note that this exposes more serious problems with the initial loading of the universal variables. While investigating this problem it became obvious that no callback events were performed during the initial loading of the uvars. The only reason that fish_escape_delay_ms happened to work as a uvar was because it was explicitly special-cased. Any other variable handled by react_to_variable_change() is not handled during the initial loading of uvars. Note that env_universal_t::load() discard the callbacks that result from loading the uvars. Which is itself a big red flag that the logic isn't correct.