Non-existent completion breaks prompt slightly

[plttn]

On 2.3.0, trying to complete a completion that doesn't exist (ex: git ---) spawns a new line/prompt, rather than just flashing the invalid suggestion.

Reproduction Steps:

1. Enter a completion that doesn't exist, git ---
2. Hit tab

   Expected behavior:

Completion background should flash

Observed behavior:

Prompt breaks slightly:

Additional information:

Noticed this change with v2.3.0.

---

Fish version: 2.3.0

Operating system: El Capitan, brew

Terminal or terminal emulator: Terminal.app

[faho]

I can't reproduce it. Can you try with a different terminal? I hear iTerm2 comes heavily recommended.

One possible cause is c79ade9627b116a0dc4aecd27d1ff61e68fe595b - we send a terminal bell when there's no completion, and it's possible your terminal reacts weirdly to that.

Or it's another case of us miscalculating the width of something - can you try resizing the terminal? And IIRC there's some option about "ambiguous width characters" - can you switch that?

[plttn]

It's reproducing on iTerm as well.

I might have something going on in my config folder functions (i've overridden one or two semi-core functions).

On Mon, May 30, 2016 at 4:34 PM Fabian Homborg notifications@github.com wrote:

I can't reproduce it. Can you try with a different terminal? I hear iTerm2 comes heavily recommended.

One possible cause is c79ade9 https://github.com/fish-shell/fish-shell/commit/c79ade9627b116a0dc4aecd27d1ff61e68fe595b

• we send a terminal bell when there's no completion, and it's possible your terminal reacts weirdly to that.

Or it's another case of us miscalculating the width of something - can you try resizing the terminal? And IIRC there's some option about "ambiguous width characters" - can you switch that?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/fish-shell/fish-shell/issues/3093#issuecomment-222565802, or mute the thread https://github.com/notifications/unsubscribe/AHByQDSAcJaSrfXnGDkuh0nKnom6Urj5ks5qG3PmgaJpZM4IqEPh .

[krader1961]

I can't reproduce on OS X using iTerm2. I don't have a right prompt which might be a factor.

[plttn]

Looks like I can narrow the issue down to something in fisherman. I'll take a look at what's causing it in there, but it's not a fish-shell core issue.

On Mon, May 30, 2016 at 4:40 PM Kurtis Rader notifications@github.com wrote:

I can't reproduce on OS X using iTerm2. I don't have a right prompt which might be a factor.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/fish-shell/fish-shell/issues/3093#issuecomment-222566153, or mute the thread https://github.com/notifications/unsubscribe/AHByQBnHWjjgg364jJUzquy8BFJJm35Zks5qG3VNgaJpZM4IqEPh .

[faho]

Keep us updated, then. I'm not sure how a script would be doing this.

[plttn]

It was most likely a version conflict coming from 2.2.0 and the fisherman I had installed on that, to something in 2.3.0. Nuked my fisher folder in ~/.config and started over with installing, and it's working fine now.

[plttn]

I lied. I'm getting the feeling it's definitely an issue with fisherman. Something it's hooking into for any theme is causing the bell jump. Doing some digging on what it would possibly be.

[faho]

Well, which prompt are you using? Or can you upload your config somewhere (screened for personal info)?

[plttn]

I'm using scorphish installed via fisherman (and nothing else from fisher). If I don't have scorphish loaded via fisher, but the fisher command still functioning, the completion bell doesn't break the terminal. If I load scorphish, it breaks the terminal.

[faho]

@pittn: I can't reproduce with https://github.com/oh-my-fish/theme-scorphish (AFAIK that's the scorphish repo). Can you try to narrow it down to a part of that? Try just the fish_prompt function (i.e. without the right prompt, the greeting and the title), and then try cutting that some - there's a lot it reacts to that might be different on your system than mine (I don't have ruby or virtualenv).

[plttn]

FWIW, It occurs with scorphish being installed from OMF as well, and doesn't occur with bobthefish, so I think this is some rare edge case with the theme itself/and my system, and not any interaction between fisherman/fish.

Looks like multiline prompts freak out, single line prompts don't.

[faho]

It occurs with scorphish being installed from OMF as well

It's the same thing. The bits are identical.

Looks like multiline prompts freak out, single line prompts don't.

Does it freak out on other multiline prompts?

[plttn]

Yeah, it also occurs on nelsonjchen (https://github.com/nelsonjchen/omf-theme-nelsonjchen).

On Tue, May 31, 2016 at 11:45 AM Fabian Homborg notifications@github.com wrote:

It occurs with scorphish being installed from OMF as well

It's the same thing. The bits are identical.

Looks like multiline prompts freak out, single line prompts don't.

Does it freak out on other multiline prompts?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/fish-shell/fish-shell/issues/3093#issuecomment-222782547, or mute the thread https://github.com/notifications/unsubscribe/AHByQD5mnT-alTFyPVMc7kMLrDGUmFpmks5qHIHMgaJpZM4IqEPh .

[faho]

Okay, if you execute

functions -e fish_right_prompt
function fish_prompt
    echo $PWD
    echo ">"
end

does it still occur? (This will not change your configuration, it will only be valid for that fish session)

Also, do you have the "Treat ambiguous-width characters as double width" option in your terminal checked (see #2451)?

[plttn]

With that prompt, the issue still occurs. I have ambiguous-width characters as double width off.

[plttn]

FWIW, the issue still occurs when I ssh into my Mac from a Windows machine, so I don't think it's an interaction between fish and the terminal.

[plttn]

Also, it's the same erroneous output as #3074 (and I'm able to repro that bug), so probably tied together somehow?

[lfiolhais]

Can reproduce with iTerm2 (3.0.3) in OS X (10.11.5) with fish built from master and simple-ass-prompt in OMF

[faho]

@plttn, @lfiolhais: Since all of the themes you've been reporting have a greeting, a prompt, a right prompt and a title function, we need to narrow this down to one of those.

The prompt and right prompt can't be it because apparently the issue also happens with no right prompt and the simplest of prompts, and the greeting seems unlikely (since it's a one-shot thing). So:

Can you please test this without the title function?

[lfiolhais]

Tested without a title and it still occurs.

[plttn]

I just redid the test prompt you did, with fish_title and fish_right_prompt being unset, and it still occurs.

[plttn]

Interestingly enough, I get the same erroneous results if I zoom a pane in tmux, on a device that wasn't exhibiting that behavior outside of tmux zooming. I know you mentioned something about the width not being calculated properly, is that still a possible cause @faho?

(To clarify, zooming out of a tmux pane with a two line prompt has the incorrect output, zooming out of a tmux pane with a one line prompt does not)

[lfiolhais]

I've tested on my Rpi and this problem doesn't occur. It might be OS X specific...

[plttn]

Still occurring in v2.3.1.

[krader1961]

FWIW, I can now reproduce this. I started a iTerm2 (latest and greatest 3.0.20160711-nightly) and macOS bog standard Terminal.app. Each window was 80 columns wide. I then ran

functions -e fish_right_prompt
function fish_prompt
    echo $PWD
    echo ">"
end

Followed by git --- then [tab]. You can see this at asciinema. The screen does flash but I also get a new prompt. Note that the asciinema capture shows a terminal that is 50 columns wide but the width doesn't appear to matter as I can reproduce with an 80 column wide terminal.

I tracked this down to commit c79ade9. If I revert the addition of writestr(L"\a"); by that change against git master the problem disappears. In fairness to @floam I don't see an obvious problem with his change even with the knowledge it has introduced this problem. I suspect it is due to the same MS Windows problem I fixed with commit 82c56bc64b5038d5d5b6fcf49d1ceb9560447790. That is, the issuance of the "bell" character is modifying the tty timestamp that then causes fish to think it needs to issue a fresh prompt.

[krader1961]

I've confirmed that the writestr(L"\a"); introduced by commit c79ade9 is causing function s_check_status() in src/screen.cpp to think the terminal content has changed without fish's knowledge. TBD is how to fix that. Function s_save_status() is private to src/screen.cpp and thus not directly available to reader_flash() in src/reader.cpp. It is only indirectly available via s_write() which is a public symbol with a very complex signature.

[floam]

Aw, darn!

[mqudsi]

I was just about to tackle this but I think @ridiculousfish beat me to it in e6863a9.