`fish_prompt` event still being sent on `read`

[charlespierce]

The changelog for 3.2.0 mentions that fish_prompt should not be sent on read and points to #7039, which indicates it was resolved and now there is a new event fish_read. However, if I create a function with --on-event fish_prompt, that function is still called when executing read:

chuck@chucks-mbp /U/chuck> function event_example --on-event fish_prompt
                               echo "FISH PROMPT EVENT"
                           end
FISH PROMPT EVENT
chuck@chucks-mbp /U/chuck> read
FISH PROMPT EVENT
read>

Fish Version: 3.3.1 and 3.4.0
No change if running fish without any customizations.

Is there a way to work around this or detect within the function that it's a read call rather than an actual prompt?

[faho]

Lovely, this apparently regressed.

[faho]

It turns out this never actually worked. It does add a fish_read event, yes, but it never stopped firing the fish_prompt event. I just built 3.2.0 and confirmed.

That's because builtin read still calls reader_readline, which fires the fish_prompt event. It just changed the second superfluous fish_prompt to a fish_read event. So before cdh would fire fish_prompt twice, and then you'd get another fish_prompt when your prompt was redrawn, where now cdh fires fish_read, then fish_prompt, and then you get another fish_prompt when your prompt is redrawn.

cc @mqudsi

[mqudsi]

Thanks, @faho. Classic case of focusing on the new feature and forgetting about the actual bug 😂