Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cdh causes the fish_prompt event to be sent twice #7039

Closed
lrworth opened this issue May 26, 2020 · 4 comments
Closed

cdh causes the fish_prompt event to be sent twice #7039

lrworth opened this issue May 26, 2020 · 4 comments
Labels
bug Something that's not working as intended
Milestone

Comments

@lrworth
Copy link

lrworth commented May 26, 2020

lukeworth@Lukes-MBP /tmp> function show_prompt_details --on-event fish_prompt
      echo fish_prompt received!
  end
fish_prompt received!
lukeworth@Lukes-MBP /tmp> cd a
fish_prompt received!
lukeworth@Lukes-MBP /t/a> prevd
fish_prompt received!
lukeworth@Lukes-MBP /tmp> cdh
 a  1)  /tmp/a
fish_prompt received!
fish_prompt received!
Select directory by letter or number:

This is particularly annoying because I was using the fish_prompt event to display a wrappable environment status (c.f. #904 (comment)).

As a workaround I am using the fish_postexec event. (Um, if anyone's using vim and this starts breaking plugins, try :set shell=sh to force POSIX shell instead of fish. TIL)

Environment

[I] ➜ echo $version
3.1.2
[I] ➜ uname -a
Darwin Lukes-MBP 19.4.0 Darwin Kernel Version 19.4.0: Wed Mar  4 22:28:40 PST 2020; root:xnu-6153.101.6~15/RELEASE_X86_64 x86_64 i386 MacBookPro11,5 Darwin
[I] ➜ echo $TERM
xterm-256color
@zanchey zanchey added the bug Something that's not working as intended label May 26, 2020
@zanchey zanchey added this to the fish-future milestone May 26, 2020
@zanchey
Copy link
Member

zanchey commented May 26, 2020

This is caused by read. It doesn't seem to me that that should fire the fish_prompt event.

@mqudsi
Copy link
Contributor

mqudsi commented May 26, 2020

I just checked and the only non-prompt related usage of fish_prompt (i.e. would be relevant to read) shipping with fish itself is enabling bracketed paste, which begs the question: is bracketed paste intentionally enabled for interactive reads executed by a command?

  • If yes, then we would stop firing fish_prompt in read and use a new event handler fish_read with an accompanying function to enable bracketed paste when it's fired.
  • If no, then we would just stop firing fish_prompt in read altogether.

@faho
Copy link
Member

faho commented May 26, 2020

is bracketed paste intentionally enabled for interactive reads executed by a command?

Yes. With what bracketed paste does, it should be enabled wherever possible.

Since read understands bracketed paste (because it runs the full bindings), it should be enabled there.

If yes, then we would stop firing fish_prompt in read and use a new event handler fish_read

That would work, yes.

@mqudsi mqudsi closed this as completed in 2d52335 May 26, 2020
@mqudsi
Copy link
Contributor

mqudsi commented May 26, 2020

Thanks, @faho, and I agree. Just pushed the commit and included a note in the changelog in case anyone was relying on the old behavior.

@zanchey zanchey modified the milestones: fish-future, fish 3.2.0 May 27, 2020
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 25, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something that's not working as intended
Projects
None yet
Development

No branches or pull requests

4 participants