bracketed-paste & gnome-terminal

bracketed-paste & gnome-terminal

[Danek Duvall]

I know there's been a lot of change in the bracketed-paste area recently,
but I don't recall seeing anything about this, and I've long since deleted
those emails.  I hope this is new ground, but maybe not.

I've upgraded to zsh 5.2 on my Solaris system.  Everything works fine for
me -- pastes into the terminal are highlighted as expected.  But if I use
gnome-terminal instead of xterm, then the bracket codes show up on the
commandline: e[200~copymee[201~.  Unsetting zle_bracketed_paste works
around the problem, but it's not clear to me what's going on that it's
broken.  I'm assuming it's an issue with gnome-terminal (or libvte), but I
didn't find any associated bugs on the gnome bugzilla.

FWIW, the terminal is, I think, rather old: 2.30.2.  The vte library is
0.26.2.  So it might be a sign of extreme age more than anything else, and
I believe we're working on upgrading those components, but in case there's
anything that zsh could/should do about this, I thought I'd ask.

Thanks,
Danek

Re: bracketed-paste & gnome-terminal

[Bart Schaefer]

On Mar 10,  2:29pm, Danek Duvall wrote:
}
} I've upgraded to zsh 5.2 on my Solaris system.  Everything works fine for
} me -- pastes into the terminal are highlighted as expected.  But if I use
} gnome-terminal instead of xterm, then the bracket codes show up on the
} commandline: e[200~copymee[201~.

Bracketed-paste works as expected in gnome-terminal on Ubuntu 12.04 LTS:
GNOME Terminal 3.4.1.1

So it does appear to be, as you suspected, terminal version related.

Re: bracketed-paste & gnome-terminal

[Danek Duvall]

On Thu, Mar 10, 2016 at 02:52:28PM -0800, Bart Schaefer wrote:

> On Mar 10,  2:29pm, Danek Duvall wrote:
> }
> } I've upgraded to zsh 5.2 on my Solaris system.  Everything works fine for
> } me -- pastes into the terminal are highlighted as expected.  But if I use
> } gnome-terminal instead of xterm, then the bracket codes show up on the
> } commandline: e[200~copymee[201~.
> 
> Bracketed-paste works as expected in gnome-terminal on Ubuntu 12.04 LTS:
> GNOME Terminal 3.4.1.1
> 
> So it does appear to be, as you suspected, terminal version related.

I see something similar when running zsh from M-x shell in emacs (something
another user pointed me at):

    $ ^[[?2004h
    ^[[?2004l

Everything's fine when it pastes, presumably because emacs' terminal emulation
doesn't support bracketed paste.

Is there any way around either of these problems, other than explicitly
unsetting zle_bracketed_paste when detecting that you're running inside an
emacs terminal or gnome-terminal?

Thanks,
Danek

Re: bracketed-paste & gnome-terminal

[Bart Schaefer]

Missed this one ...

On Mar 14, 12:57pm, Danek Duvall wrote:
}
} I see something similar when running zsh from M-x shell in emacs (something
} another user pointed me at):
} 
}     $ ^[[?2004h
}     ^[[?2004l
} 
} Everything's fine when it pastes, presumably because emacs' terminal
} emulation doesn't support bracketed paste.

Emacs terminal emulation always behaves as if bracketed-paste were in
effect, because it's not attempting to do live interaction with the
program running in the buffer -- that is, you do all your editing in
the emacs buffer without anything being sent to the shell, and then
when you finally press enter (or equivalent binding) it all gets
transmitted at once.

So emacs has no reason to recognize escapes that differentiate a paste
from any other kind of input.

} Is there any way around either of these problems, other than
} explicitly unsetting zle_bracketed_paste when detecting that you're
} running inside an emacs terminal or gnome-terminal?

No, not that I can think of.

These are among the reasons that I think bracketed-paste ought to have
been something you have to explicitly turn ON, rather than something
you have to turn off, but consensus went the other way.

-- 
Barton E. Schaefer

Re: bracketed-paste & gnome-terminal

[Daniel Shahaf]

Bart Schaefer wrote on Sun, Mar 20, 2016 at 11:34:19 -0700:
> These are among the reasons that I think bracketed-paste ought to have
> been something you have to explicitly turn ON, rather than something
> you have to turn off, but consensus went the other way.

We could have $zle_bracketed_paste default to unset for TERM == emacs,
if emacs users think that's a good idea.

Re: bracketed-paste & gnome-terminal

[Danek Duvall]

On Mon, Mar 21, 2016 at 04:08:22PM +0000, Daniel Shahaf wrote:

> Bart Schaefer wrote on Sun, Mar 20, 2016 at 11:34:19 -0700:
> > These are among the reasons that I think bracketed-paste ought to have
> > been something you have to explicitly turn ON, rather than something
> > you have to turn off, but consensus went the other way.
> 
> We could have $zle_bracketed_paste default to unset for TERM == emacs,
> if emacs users think that's a good idea.

Except that emacs now seems to set TERM=dumb -- at least on GTK+ GNU emacs
24.5.1, that we're currently running on Solaris -- so I'm not sure how
reliable that'll be.  Is there a better way to check for running inside
emacs?

Danek

Re: bracketed-paste & gnome-terminal

[Bart Schaefer]

On Mar 21,  9:38am, Danek Duvall wrote:
}
} Except that emacs now seems to set TERM=dumb [...]
} Is there a better way to check for running inside emacs?

Some versions of emacs export EMACS=t into the environment.  I don't know
how reliable that is, either.

I have this in .zshrc; I have no recollection of how old that "eterm"
comment is:

case ${TERM:-dumb} in
emacs|dumb)
    [[ $EMACS = t ]] || return 0
    export TERMCAP='emacs|:am:bl=:cr=^M:do=^J:sf=^J:'
    TERM=emacs 2>/dev/null
    export EDITOR=emacs
    stty -onlcr -echo
    ttyctl -f
    ;;
#  eterm)
#      # This is bad; eterm is the Enlightenment terminal emulator name.
#      # Recent versions of emacs now use 'emacs-em7930' and stuff their
#      # own termcap or terminfo into the process environment.
#      TERM=vt100
#      ;;
esac

Re: bracketed-paste & gnome-terminal

[Bart Schaefer]

On Mar 21,  4:08pm, Daniel Shahaf wrote:
}
} We could have $zle_bracketed_paste default to unset for TERM == emacs,
} if emacs users think that's a good idea.

We currently don't have any kind of default terminal type handling built
into the shell.  There are a couple of things that attempt to use
terminfo/cap booleans, but nothing that examines terminal name.

Re: bracketed-paste & gnome-terminal

[Daniel Shahaf]

Bart Schaefer wrote on Mon, Mar 21, 2016 at 10:10:42 -0700:
> On Mar 21,  4:08pm, Daniel Shahaf wrote:
> }
> } We could have $zle_bracketed_paste default to unset for TERM == emacs,
> } if emacs users think that's a good idea.
> 
> We currently don't have any kind of default terminal type handling built
> into the shell.  There are a couple of things that attempt to use
> terminfo/cap booleans, but nothing that examines terminal name.

Sure, ideally we'd ask terminfo whether bracketed paste is supported
[and what the control sequences for it are], but if the only practical
way to detect being in emacs would turn out to be by literally checking
the value of getenv("TERM"), I wouldn't mind that, so long as it
wouldn't break xterm/vim/etc.

Cheers,

Daniel

Re: bracketed-paste & gnome-terminal

[Danek Duvall]

On Thu, Mar 10, 2016 at 02:52:28PM -0800, Bart Schaefer wrote:

> On Mar 10,  2:29pm, Danek Duvall wrote:
> }
> } I've upgraded to zsh 5.2 on my Solaris system.  Everything works fine for
> } me -- pastes into the terminal are highlighted as expected.  But if I use
> } gnome-terminal instead of xterm, then the bracket codes show up on the
> } commandline: e[200~copymee[201~.
> 
> Bracketed-paste works as expected in gnome-terminal on Ubuntu 12.04 LTS:
> GNOME Terminal 3.4.1.1
> 
> So it does appear to be, as you suspected, terminal version related.

I did a bit more digging, and discovered that it's actually compiler
related.  We build vte with Studio 12.3, but if I build with gcc 4.8, the
problem goes away.  The problem exists with newer versions of Studio as
well.  I don't know yet whether this is a compiler bug or some weird header
or standards mode interaction.  But it's not a zsh bug.  :)

Thanks,
Danek