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

iTerm2 on OSX is warning about "paste bracketing being left on" for 2.7.1b #4521

Closed
psbanka opened this issue Nov 3, 2017 · 45 comments
Closed
Labels
bug Something that's not working as intended needs more info
Milestone

Comments

@psbanka
Copy link

psbanka commented Nov 3, 2017

fish version: 2.7.1b
OS: Darwin 17.0.0 Darwin Kernel Version 17.0.0; root:xnu-4570.1.46~2/RELEASE_X86_64 x86_64
$TERM: xterm-256color

Steps to reproduce:

  • Download and install iterm2 for OS X
  • Install 2.6.0 of fish and set default shell (no problems)
  • Upgrade fish to 2.7.1b
  • Restart iTerm2

See a message at the top of the terminal: "Looks like paste bracketing was left on when an ssh session ended unexpectedly or an app misbehaved. Turn it off? (Yes/ Always/ Never)"

screen-shot

@faho
Copy link
Member

faho commented Nov 6, 2017

The only change to our bracketed paste handling since 2.6.0 was 4ff002b, which was supposed to turn it off when fish exits, so this is rather perplexing.

So, @psbanka: Just to be clear:

  • You start iTerm2, with fish
  • You exit iTerm2 without closing fish via exit or ctrl-d or something
  • You start iTerm2 again and the message appears?
  • You can reproduce this with just 2.7b1 (i.e. the "upgrade fish" step is unecessary to reproduce the bug)?

This is something I'd expect with 2.6.0, since that does not turn off bracketed paste when fish dies, so if you upgraded and it just happened that once it'd be something we already fixed (and the detection was presumably just added to iTerm2). But if it happens with 2.7b1 that would be weird.

@psbanka
Copy link
Author

psbanka commented Nov 6, 2017

Yes, just went through those exact steps. You can see me opening and closing tabs/windows in this
screen-cap

It turned out I had both fish 2.6.0 installed and fish 2.7.1b installed. I uninstalled both and then installed the newest version alone with brew install --devel fish ... however the problem remains.

@faho
Copy link
Member

faho commented Nov 6, 2017

And if you click "Yes" (not "Always" or "Never") on that message it'll just occur again?

Because if it doesn't it could just be iTerm remembering what fish 2.6.0 did.

Otherwise I'm still struggling to figure out how fish 2.7b1 could in any way make this worse.

@faho faho added bug Something that's not working as intended needs more info labels Nov 6, 2017
@psbanka
Copy link
Author

psbanka commented Nov 6, 2017

That is correct screen-cap

@faho
Copy link
Member

faho commented Nov 6, 2017

Since, as I said, the only change to bracketed paste from 2.6.0 is to turn it off also when fish exits, can you try reverting that? You don't need to actually git revert it, executing the following interactively should be enough:

function __fish_disable_bracketed_paste --on-event fish_preexec
    printf "\e[?2004l"
end

That'll redefine the function without --on-process-exit %self.

Note that, if this succeeds, it's a bug in iTerm2 - the detection would be wrong.


If that doesn't work, we're going to need to re-check some assumptions.

@psbanka
Copy link
Author

psbanka commented Nov 6, 2017

Okay, I don't have much of an idea what any of this is doing, but I'm happy to follow directions and report results. So pasting in that function and executing it and then opening new terminals does not seem to have any affect.

screen cap

@leewalsh
Copy link

leewalsh commented Nov 23, 2017

This just started happening for me when I upgraded from 2.6.0 to 2.7.0.

It may have something to do with iTerm's shell integration and detecting the shell prompt. It works by adding some lines to your fish_prompt function that emit control codes. When a prompt is detected, it prints that little blue triangle mark by the prompt. You can see it in @psbanka's screen captures, but only on the first prompt. When the feature is working correctly, it shows on all prompts. I do not have it enabled, and never saw the mark before upgrading to 2.7.0, but now it shows on the first prompt after changing directories:
iterm_fish_prompt_mark_on_cd

I have the shell integration installed on another computer that is still running fish 2.6, so I can see if that changes anything (but cannot test it yet). (By the way, is there an easy way to clear fish's configuration files for a single session, for a kind of "safe-mode", for testing these things?)

@charleskorn
Copy link

I'm also seeing this issue after upgrading to 2.7.0. Is there any information I can share that will help you track down the issue?

@REBELinBLUE
Copy link

REBELinBLUE commented Nov 24, 2017

Yep, ditto. I don't have iTerm's shell integration enabled either. This is my fish setup https://github.com/REBELinBLUE/dotfiles/tree/master/files/shell/fish

@leewalsh
Copy link

leewalsh commented Nov 24, 2017

At work now with the computer with shell integration enabled. Just went through carefully watching behavior before upgrading fish, and then after upgrading fish, I did not get any of the paste bracketing warnings. Here is what it looks like at 2.6.0:
iterm_fish_shell_prompt_paste_bracketing3

Turns out it looks the same with 2.7.0:
iterm_fish_shell_prompt_paste_bracketing-270

Not sure if this is helpful, but my prompt did not change across the upgrade, and it shows (with shell integration enabled):

leewalsh@warbler ~> string escape (fish_prompt)
\e\[1m\e\[32mleewalsh\e\[30m\e\(B\e\[m@\e\[1m\e\[36mwarbler\e\[30m\e\(B\e\[m\ \e\[32m\~\e\[30m\e\(B\e\[m\e\[30m\e\(B\e\[m\>\ \e\]133\;B\cg

And on the other computer, with shell integration disabled:

~/C/bugs $ string escape (fish_prompt)
\e\[32m\e\[4m\e\[32m\~\e\[30m\e\(B\e\[m\e\[32m/C/bugs\e\[30m\e\(B\e\[m\ \$\ \e\[30m\e\(B\e\[m

@zanchey
Copy link
Member

zanchey commented Nov 24, 2017

Can share how iTerm is configured to launch fish (ie run command, login shell, exec from .bashrc)?

@leewalsh
Copy link

leewalsh commented Nov 24, 2017

Can share how iTerm is configured to launch fish (ie run command, login shell, exec from .bashrc)?

fish is my login shell, and iTerm is configured to launch "Login shell." I believe that's the default setting for iTerm, and my login shell was set as recommended by homebrew:

==> Caveats
You will need to add:
  /usr/local/bin/fish
to /etc/shells.

Then run:
  chsh -s /usr/local/bin/fish
to make fish your default shell.

@richrad
Copy link

richrad commented Nov 24, 2017

I'm getting this too after upgrading from 2.6.0 to 2.7.0. Let me know if there's anything I can paste in to help!

@faho
Copy link
Member

faho commented Nov 24, 2017

(By the way, is there an easy way to clear fish's configuration files for a single session, for a kind of "safe-mode", for testing these things?)

@leewalsh: What we recommend in our issue template is sh -c 'env HOME=$(mktemp -d) fish' - i.e. launching fish with a temporary home directory.


So, what is still confusing me here is that the only change in 2.7.0 related to bracketed paste is turning it off when fish exits (i.e. doing the very thing that iTerm says it's not).

Alternatively, since this seems to be a shell integration thing, it'd be possible that the various event-triggered functions here interfere with each other. We don't actually run any of them in the background or more than one at a time, but I'm not sure if they are always triggered in the same order.

So what I'm assuming is:

  • iTerm has one escape it does to signal the beginning of the prompt
  • It has another to signal the end
  • At least some of the time, the bracketed paste end is signalled between these two, so iTerm gets confused

For some reason, iterm has both "precmd" and "preexec" functions, but they are triggered when the $_ variable changes, not by fish's native events.

What I'd love to see, @leewalsh, @psbanka, @charleskorn, @richrad, is a recording with asciinema. That way we can both see what is happening and still check the full output.

Also, since I'm a bit confused, could everyone tell me again if they see this just with shell integration enabled or without it as well?

@faho
Copy link
Member

faho commented Nov 24, 2017

And also please try to reproduce with an empty fish configuration - i.e. just move ~/.config/fish away for a bit and open a new session. If that changes anything, please report any custom functions and third-party scripts (OMF, fisherman, ...) you are using.

@chamini2
Copy link

Still reports with an empty fish configuration.

@faho
Copy link
Member

faho commented Nov 24, 2017

Oh, one more thing: Because this might be remembered from a previous session and I'm not sure if it's cleared by iTerm, click "Yes" on the notification before checking anything.

@leewalsh
Copy link

@faho, Here is a summary for two different computers what and warbler, each running iTerm2 3.1.5.beta.2.

  1. leewalsh@what shell integration disabled
    screenshots in my first comment

    1. fish 2.6.0:
      • no warning
      • no prompt markers
    2. fish 2.7.0:
      • warning: Looks like paste bracketing was left on
      • prompt markers on first prompt after each cd
  2. leewalsh@warbler shell integration enabled
    screenshots in my second comment
    no change, i.e.:

    1. fish 2.6.0:
      • no warning
      • prompt markers
    2. fish 2.7.0:
      • no warning
      • prompt markers

Anything in particular you'd like to see on asciinema? I can do what is in the screenshots again if you just want to see it live. I assume that it won't record the warning or the prompt marks, but maybe it grabs escape codes? I will also test with a clean config for fish and iterm when I get the chance.

@faho
Copy link
Member

faho commented Nov 24, 2017

prompt markers on first prompt after each cd

You know, that's quite confusing. The prompt markers are enabled by iterm's shell integration, so there's something going on here.

I assume that it won't record the warning or the prompt marks, but maybe it grabs escape codes?

It'll grab all the output of the fish process, which includes escape codes - including those making up the prompt marks (i.e. it wouldn't show the neat marker character, but \e]133;A\007 and \e]133;B\007 - the sequences iTerm uses to mark the prompt).

Anything in particular you'd like to see on asciinema?

Since this seems to be triggered on cd for you, I'd like to see a cd, something that isn't a cd (e.g. echo something) and just for good measure builtin cd (in case something's overriding our cd function).

Also the output of env would be nice (but it doesn't need to be in asciinema).

As always, feel free to censor anything you consider to be personal information - I want to know about your bug, not your bank details.

@charleskorn
Copy link

I've made a recording of what I'm seeing at https://asciinema.org/a/EQaQlJnYGbe2nfWakdGeIZcMC.

env gives me:

Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.wyiKuokIiy/Render
COLORFGBG=15;0
COLORTERM=truecolor
DISPLAY=/private/tmp/com.apple.launchd.IUWZgVvcYc/org.macosforge.xquartz:0
HOME=/Users/charleskorn
ITERM_PROFILE=Default
ITERM_SESSION_ID=w0t0p0:2A24DE74-6C3D-425B-A051-64B6E0B90D90
JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home
LANG=en_AU.UTF-8
LOGNAME=charleskorn
PATH=/Applications/Sublime Text.app/Contents/SharedSupport/bin:/Users/charleskorn/Library/Android/sdk/platform-tools:/Users/charleskorn/Library/Android/sdk:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin
PWD=/Users/charleskorn
SHELL=/usr/local/bin/fish
SHLVL=1
SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.XcdDfYPEGA/Listeners
TERM=xterm-256color
TERM_PROGRAM=iTerm.app
TERM_PROGRAM_VERSION=3.1.5.beta.2
TERM_SESSION_ID=w0t0p0:2A24DE74-6C3D-425B-A051-64B6E0B90D90
TMPDIR=/var/folders/tf/w8t0nnrx2b72sh3wwl4njq1r0000gn/T/
USER=charleskorn
XPC_FLAGS=0x0
XPC_SERVICE_NAME=0
__CF_USER_TEXT_ENCODING=0x1F5:0x0:0xF

Let me know if there's anything else that would be helpful.

@Konstruktionist
Copy link

Konstruktionist commented Nov 25, 2017

I had the same symptoms as the original poster after upgrading to fish 2.7.0.

iTerm2 version is 3.1.5

  • warning
  • markers

I have never installed Shell Integration from the iTerm menu. So I looked around in the iTerm Preferences.
Under Profiles > Terminal there is a setting that's not immediately obvious (because it is not visible). You have to scroll down in the panel (there's stuff below the Environment label --> Shell Integration). I unticked both checkboxes & answered Never on the warning message.

Now I have

  • no warning
  • no markers

@faho
Copy link
Member

faho commented Nov 25, 2017

I've made a recording of what I'm seeing at https://asciinema.org/a/EQaQlJnYGbe2nfWakdGeIZcMC.

Huh...

@charleskorn: Did that session exhibit the prompt marks for you? Do you otherwise get them?

Because, looking at the json, I'm not seeing any of iTerm's proprietary escape codes nor any sign of the shell integration. It also includes the bracketed paste end sequence (\e\[?2004l) as the very last line. In fact it sends that twice after the last opening (once because the exit command ended and once because fish quits).

What I'd like to find out is if that session actually triggers the issue. Can you set your shell to bash (assuming that doesn't handle bracketed paste itself), then asciinema play that session and exit bash? If after that iTerm also shows the notification, then that session reproduces the problem.

@gViro
Copy link

gViro commented Nov 25, 2017

I was having this issue with iTerm2 ( 3.1.5 ) as well on an early 2015 mbp ( OSX 10.12.6 ) and Konstruktionist's workaround has 'fixed' it.

@Darkshadow2
Copy link
Contributor

@faho If you leave on the option Show mark indicators (one of the options @Konstruktionist mentioned), the very first prompt in your session will show an indicator even if you have Shell Integration turned off, and without sending the escape codes. That's probably why it's not putting them out in the recording - they're not there (unless @charleskorn has Shell Integration enabled). I think iTerm does a best guess at your prompt in that case and since it never gets the escape code saying the prompt ended, only marks the first one.

To note, I actually got this warning back when bracketed paste was first implemented (whenever that was - 2.6? I keep up with whatever is in master). I just told iTerm to always turn it off so I don't get the notification, but bracketed paste still works fine.

I actually tried to go turn the warning back on to see if I still get it, but I can't figure out how to do that one. Doesn't seem to be in the preferences anywhere. The only option about it is under the Advanced preferences, and reads Always turn off paste bracketing when host changes? which is set to No so I don't think that's it.

@richrad
Copy link

richrad commented Nov 25, 2017

@Darkshadow2 I found it hiding in ~/Library/Preferences/com.googlecode.iterm2.plist – I think it's NoSyncHaveWarnedAboutPasteConfirmationChange

@Darkshadow2
Copy link
Contributor

@richrad Thanks, though I'm not sure that's it. I quit iTerm, launched Terminal, and used defaults to delete that key from iTerm's preferences (then used it to make sure it was actually deleted). Then I quit Terminal and relaunched iTerm. I did not get a warning, but reading iTerm's preferences showed that NoSyncHaveWarnedAboutPasteConfirmationChange was set again without me doing anything.

@leewalsh
Copy link

leewalsh commented Nov 25, 2017

@Darkshadow2, @richrad, In the plist file you'll have <key>NoSyncTurnOffBracketedPasteOnHostChange</key> as true or false if the advanced pref is set to Yes or No, and the line won't be there if it is set to unspecified. @Darkshadow2, if you want to get the warning again, set it to unspecified.

leewalsh@warbler ~> grep -A1 Brack Library/Application\ Support/iTerm/com.googlecode.iterm2.plist
	<key>NoSyncTurnOffBracketedPasteOnHostChange</key>
	<false/>
leewalsh@warbler ~> grep -A1 Brack Library/Application\ Support/iTerm/com.googlecode.iterm2.plist
	<key>NoSyncTurnOffBracketedPasteOnHostChange</key>
	<true/>
leewalsh@warbler ~> grep -A1 Brack Library/Application\ Support/iTerm/com.googlecode.iterm2.plist
leewalsh@warbler ~ [1]>

@richrad
Copy link

richrad commented Nov 25, 2017

@Darkshadow2 Sorry about that, I think I realized it was the wrong one right after I posted this. I've found that there are a couple "NoSync" keys in there that say something about bracketed paste. Nuking 'em all brings back the warning for me. I've had to remove them twice sometimes before it stuck but I think that has to do with the timing of when I edit the file and whether or not iTerm is running when I make the changes.

@Darkshadow2
Copy link
Contributor

@leewalsh Ah, you're right. They need to word that setting better...

So, turning that to unspecified does show the warning for me again. So, anyone who doesn't want to get warned, just go to Advanced and turn Always turn off paste bracketing when host changes? to No. You won't get the warning and bracketed paste will still work fine.

And interesting, I could swear back when I did it I told iTerm to always turn it off (which would have been 'Yes' under that setting). If I set it to Yes now, though, it does disable bracketed paste. Though that was a few versions ago, maybe the way it was set has changed. Or maybe I'm just remembering wrong.

Also interesting that even though I removed that from iTerm's preferences, it still remembered. I wonder if there's more than one? Or maybe iTerm was changed recently to default that warning to off.

@charleskorn
Copy link

@charleskorn: Did that session exhibit the prompt marks for you? Do you otherwise get them?

I get the prompt marks on the initial prompt, the prompt where I then type builtin cd, the prompt where I type echo test, but not on the last prompt (after echo test and where I type exit). I wasn't seeing them at all until I upgraded to 2.7.0.

Because, looking at the json, I'm not seeing any of iTerm's proprietary escape codes nor any sign of the shell integration. It also includes the bracketed paste end sequence (\e[?2004l) as the very last line. In fact it sends that twice after the last opening (once because the exit command ended and once because fish quits).

What I'd like to find out is if that session actually triggers the issue. Can you set your shell to bash (assuming that doesn't handle bracketed paste itself), then asciinema play that session and exit bash? If after that iTerm also shows the notification, then that session reproduces the problem.

Just tried that now... the warning appears as soon as I start playback. If I then open another tab that runs bash (rather than my default of fish), I don't see the warning.

@faho
Copy link
Member

faho commented Nov 28, 2017

Just tried that now... the warning appears as soon as I start playback.

So they appear at the first prompt, or after the first command or so?

This is really confusing me. The best theory I can come up with is that iTerm, with the "shell integration" setting (not the script) turned on, figures out where fish's prompt is and then sees that bracketed paste is on and assumes it is wrong.

There is bb29f9f, which changed the $PWD reporting. This might explain how iTerm is getting these prompt marks and why they only appear when $PWD changes, and how it is only happening in 2.7.0 and not 2.6.0.

However, that would mean it's an iTerm bug. Has anyone tried contacting @gnachman?

@charleskorn
Copy link

Just tried that now... the warning appears as soon as I start playback.

So they appear at the first prompt, or after the first command or so?

Yep, before I even type anything, I see that warning.

@arkbriar
Copy link
Contributor

arkbriar commented Nov 30, 2017

LATEST UPDATE:

328439, this is the root cause in fish commits, which added iTerm into the update_pwd list.

Remove "$TERM_PROGRAM" = "iTerm.app" and everything's fine!

diff --git a/share/functions/__fish_config_interactive.fish b/share/functions/__fish_config_interactive.fish
index e29c1fc2..dbd57ebc 100644
--- a/share/functions/__fish_config_interactive.fish
+++ b/share/functions/__fish_config_interactive.fish
@@ -271,7 +271,7 @@ function __fish_config_interactive -d "Initializations that should be performed
     or set -l VTE_VERSION 0
     set -q TERM_PROGRAM
     or set -l TERM_PROGRAM
-    if test "$VTE_VERSION" -ge 3405 -o "$TERM_PROGRAM" = "Apple_Terminal" -o "$TERM_PROGRAM" = "iTerm.app"
+    if test "$VTE_VERSION" -ge 3405 -o "$TERM_PROGRAM" = "Apple_Terminal"
         function __update_cwd_osc --on-variable PWD --description 'Notify capable terminals when $PWD changes'
             if status --is-command-substitution
                 or set -q INSIDE_EMACS

UPDATE:

I do some experimental fixes to solve this problem. I can't guarantee that I have understood the behavior of iTerm2 correctly and this does not introduce new or even more critical bugs.

Here's the patch. Apply to the latest commit of iTerm2 then we have no warning on start and no markers on PWD reporting, while shell-integrations still work.

diff --git a/sources/VT100Screen.m b/sources/VT100Screen.m
index 7fa70128..712b0024 100644
--- a/sources/VT100Screen.m
+++ b/sources/VT100Screen.m
@@ -3263,7 +3263,7 @@ static NSString *const kInilineFileInset = @"inset";  // NSValue of NSEdgeInsets
     int cursorLine = [self numberOfLines] - [self height] + currentGrid_.cursorY;
     VT100RemoteHost *remoteHostObj = [self setRemoteHost:host user:user onLine:cursorLine];

-    if (![remoteHostObj isEqualToRemoteHost:currentHost]) {
+    if (currentHost && ![remoteHostObj isEqualToRemoteHost:currentHost]) {
         [delegate_ screenCurrentHostDidChange:remoteHostObj];
     }
 }
@@ -3285,7 +3285,7 @@ static NSString *const kInilineFileInset = @"inset";  // NSValue of NSEdgeInsets
         [self setHost:host user:user];
     }
     [self terminalCurrentDirectoryDidChangeTo:path];
-    [delegate_ screenPromptDidStartAtLine:[self numberOfScrollbackLines] + self.cursorY - 1];
+    // [delegate_ screenPromptDidStartAtLine:[self numberOfScrollbackLines] + self.cursorY - 1];
 }

 - (void)terminalClearScreen {

ORIGINAL:

I have just tested the PWD reporting manually in bash using

printf '\033]7;file://ArkMac.local/Users/arkbriar\a'

and got markers on every execution.

image

And as iTerm2 declares that it supports OSC7, I think this should be an iTerm bug. (Okay, maybe a feature?)

I have found that currentHost is nil when a tab/window is created in iTerm2 sources/VT100Screen.m:3249 so a host did changed warning is fired.

And bash does not do OSC7 current dir reporting so bash does not have this warning.

- (void)setHost:(NSString *)host user:(NSString *)user {
    VT100RemoteHost *currentHost = [self remoteHostOnLine:[self numberOfLines]];
    if (!host || !user) {
        // A trigger can set the host and user alone. If remoteHost looks like example.com or
        // user@, then preserve the previous host/user. Also ensure neither value is nil; the
        // empty string will stand in for a real value if necessary.
        VT100RemoteHost *lastRemoteHost = [self lastRemoteHost];
        if (!host) {
            host = [[lastRemoteHost.hostname copy] autorelease] ?: @"";
        }
        if (!user) {
            user = [[lastRemoteHost.username copy] autorelease] ?: @"";
        }
    }

    int cursorLine = [self numberOfLines] - [self height] + currentGrid_.cursorY;
    VT100RemoteHost *remoteHostObj = [self setRemoteHost:host user:user onLine:cursorLine];

    if (![remoteHostObj isEqualToRemoteHost:currentHost]) {
        [delegate_ screenCurrentHostDidChange:remoteHostObj];
    }
}

arkbriar added a commit to arkbriar/fish-shell that referenced this issue Nov 30, 2017
@floam
Copy link
Member

floam commented Nov 30, 2017

And bash does not do OSC7 current dir reporting so bash does not have this warning.

Sure it does, on macOS. But I guess just for Terminal.app. See /etc/bashrc_Apple_Terminal.

@arkbriar
Copy link
Contributor

Sure it does, on macOS. But I guess just for Terminal.app. See /etc/bashrc_Apple_Terminal.

Ah, I see it.

And I have found the commit that leads to warning and markers. Maybe I should submit a PR?

@floam
Copy link
Member

floam commented Nov 30, 2017

If I understand how iTerm should be working, those markers are supposed to show up on every prompt, not be non-existant? Shouldn't we be doing the hostname/cwd update on every new prompt instead of on directory changes for it and trying to take care of the warnings some other way?

@arkbriar
Copy link
Contributor

Actually I haven't enabled the shell-integration for fish.

There's another way to add markers to marker cache (besides OSC7). So It's easy to have markers before every prompt.

image

@arkbriar arkbriar mentioned this issue Dec 3, 2017
3 tasks
@getaaron
Copy link

getaaron commented Dec 17, 2017

@ridiculousfish @zanchey Could we please cut a 2.7.1 release (or 2.7.0.1?) with this fix in it?

🐠

@zanchey
Copy link
Member

zanchey commented Dec 17, 2017

I'm still struggling to understand this. Is this an iTerm bug exposed by fish fixed by a workaround? Or a fish bug with a proper fix? Or something else entirely?

@faho
Copy link
Member

faho commented Dec 17, 2017

Is this an iTerm bug exposed by fish fixed by a workaround?

@zanchey: My best explanation is this:

  • When we print the PWD sequence, iTerm uses it to mark the prompt

  • We don't print it every time, so iTerm doesn't catch some prompts (which means the blue squares don't show up)

  • Since we enable bracketed paste for these prompts, iTerm thinks an application is running with bracketed paste enabled

So I don't think there's a real iTerm bug here (though I do believe that message is quite overzealous). I'm also not sure how to actually fix it. Maybe sending the $PWD sequence on every prompt does it? But that just throws up more questions - does it need to be before the bracketed paste sequence (which would make our solution quite fragile as we don't have any way to order event listeners), or does it just need to be on the same line or within a certain timeframe? Or maybe we'd need to actually do the full iTerm integration thing? Or maybe iTerm should stop using the $PWD sequence as an indication of a prompt?

@chamini2
Copy link

#4607

@zanchey
Copy link
Member

zanchey commented Dec 22, 2017

OK, that makes sense. The omnibus commit which added the behaviour makes me wonder whether it was deliberate, but I think backing it out makes sense.

I'll try and put a point release out in the next day or two.

zanchey added a commit that referenced this issue Dec 22, 2017
Fixes #4521.

(cherry picked from commit 5faa425)
@zanchey zanchey added this to the fish 2.7.1 milestone Dec 22, 2017
@gnachman
Copy link

gnachman commented Jan 7, 2018

Sorry for showing up late to this party. I hope I can still help.

When we print the PWD sequence, iTerm uses it to mark the prompt

OSC 7 causes iTerm2 to mark the start of the prompt. If paste bracketing is on at the time OSC 7 is received and the hostname in OSC 7 does not equal the existing hostname, you get the warning.

We don't print it every time, so iTerm doesn't catch some prompts (which means the blue squares don't show up)

Print it every time. I followed Terminal.app's lead on handling OSC 7 for prompt detection.

So I don't think there's a real iTerm bug here (though I do believe that message is quite overzealous).

I'll change iTerm2 to not show the warning the first time we get a hostname.

does it need to be before the bracketed paste sequence (which would make our solution quite fragile as we don't have any way to order event listeners), or does it just need to be on the same line or within a certain timeframe? Or maybe we'd need to actually do the full iTerm integration thing? Or maybe iTerm should stop using the $PWD sequence as an indication of a prompt?

Paste bracketing must be off at the time you send OSC 7. Is that feasible?

FYI similar warnings exist for mouse reporting and focus reporting, if you plan to use those.

gnachman added a commit to gnachman/iTerm2 that referenced this issue Jan 7, 2018
…eporting when we transition from no hostname to having a hostname. See fish-shell/fish-shell#4521
@faho
Copy link
Member

faho commented Jan 7, 2018

Sorry for showing up late to this party. I hope I can still help.

Better late than never! I think we still have some potato salad left.

OSC 7 causes iTerm2 to mark the start of the prompt. If paste bracketing is on at the time OSC 7 is received and the hostname in OSC 7 does not equal the existing hostname, you get the warning.

Aaah. So I basically got it half-right.

Print it every time. I followed Terminal.app's lead on handling OSC 7 for prompt detection.

Okay.

Paste bracketing must be off at the time you send OSC 7. Is that feasible?

It'll require some more work from us, but yeah, it's doable. I can see why you'd want this, so we'll figure something out.

@psbanka
Copy link
Author

psbanka commented Jan 16, 2018

Thanks, folks. 2.7.1 confirmed fixed.

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 needs more info
Projects
None yet
Development

No branches or pull requests