public inbox for
help / color / mirror / Atom feed
From: Linda Walsh <>
To: "" <>
Subject: Re: Disable xterm auto-wrap: Mess up vi-like command line
Date: Tue, 31 Mar 2015 18:36:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Paul wrote:
> If I disable auto-wrap, the vi editing at the comand line misbehaves
> when the line being edited is long, especially when yanking a lot of
> text and pasting it.  I suppose that this might be technically correct
> behaviour, since an extra long command line needs to wrap in order to
> see it properly.  But I use the vi command line exclusively, and
> almost always, I don't want autowrap in the results from commands
> being sent to the screen.  Is there a way to get both at the same
> time, without having to always toggle the xterm autowrap?
What do you mean by "mess up"?  It "shouldn't".  I just cut and pasted some text
from an xterm into an editor, and the lines weren't split... they got copied as
one line.

However, if I was to cut from a Windows Console window (cmd.exe for example),
it DOES, physically, split long lines.

It's a property of the console.

The main problem I've seen in bash is when you paste content that has
tabs in it.  Then bash tries to auto complete in the middle of your 
typing... often asking a question or pausing -- which means it *swallows* 
up the tab and 1-2 keys after the tab.

It didn't use to do this back in the 3.x series, but was added as a new
feature in the 4.x series.  

I ended up changing my "completion character" to BACKQUOTE to try to get
around this. 

Maybe tabs are causing your problem?

Example.  At a prompt, I typed:
cat "<CR>
<completion char>

(I hit enter after that first quote and went to the next line and hit
my completion char (BACKQUOTE "`"), Then I got:
> cat "
Display all 186 possibilities? (y or n)
At this point, whatever character is next in my paste buffer will be
swallowed up (in addition to the completion character).


Since the long line cut/paste worked for me in 'xterm', that's why I
thought maybe you were hitting bash'es "input mangling"-feature!...

Unsubscribe info:
Problem reports:

      reply	other threads:[~2015-03-19 23:14 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-24 15:00 Paul
2015-03-31 18:36 ` Linda Walsh [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).