Trailing spaces when copying from console

Copy & pasting from a terminal screen is never going to be fully reliable because it's dealing with screen output instead of original source material. If some applications echo text to the terminal in an unusual fashion and it results in the terminal not being able to guess what the original text was, there's probably not much you or the terminal can do about it.

A lot of information about the original text is potentially lost when it is rendered to a terminal: for example whether an area of white-space was produced by a tab or by a series of spaces, or whether two rows of text were originally one long line that got wrapped or two separate lines.

The terminal tries to do its best to let you copy & paste the original text that got echoed to the terminal but it cannot always know.

As an experiment, try this:

Use less to view a file that contains very long lines that wrap across multiple terminal lines.
Triple-click one of those lines (for select-whole-line). less selected the entire logical line that spans multiple physical lines and if you pasted it elsewhere it would be preserved as one long line.
Press j some number of lines so that part of that long line disappears off the top of the screen.
Press k one or more times to scroll the whole logical line back into view.
Triple-click the logical line again. This time only one physical line is selected. That is because less repainted the screen physical line by physical line and the terminal no longer has any way of knowing that the physical lines were connected together.
Now if you were to drag-select the entire logical line manually and paste it elsewhere, you would find that it has embedded newlines.

YMMV on that experiment because your terminal (or version of less) might be more or less clever than mine.

Generally, the dumber the software that produced the output, the better your chances are of being able to copy & paste exactly the original material. cat, for one, is pretty much as dumb as it gets.^{(You understand of course that "dumb" is a compliment!)}

If you get an extra space character at the end of a line under tmux, it's probably because tmux is actually echoing that character. Remember that tmux does its own terminal emulation and then re-emits new terminal sequences to render to the underlying terminal. Perhaps it is echoing that space character because it believes there might be a need in some cases to overwrite some other character it thinks might be there. Whatever the reason, the terminal probably has no way of knowing that space character is not really part of the original content.

You'll have spaces at the end of the line when selecting and copying from the terminal if the application displayed spaces at that spot. Applications may display spaces in order to erase what was there before. Terminals have commands to delete a whole line or delete characters to the right of the cursor; applications choose between that and displaying spaces based on what they consider most efficient. For example, if you type some stuff at a prompt, then press Backspace, the application (e.g. the shell) is likely to overwrite the last character with a space.

If you have an X11 connection, you can use xsel or xclip to copy a file to the local clipboard.

Experimentally, Vim seems to go through pains not to display lines ending with spaces (even when the buffer contains a line that ends with spaces). So copying from that is an option if you don't have an X11 connection.

An alternative would be to post-process after copying:

xsel | sed 's/  *$//' | xsel

That's actually several questions, and none of the answers do more than skim over the interesting parts:

when you select text with mouse in console (that is, copy it), paste it, and realize you've got extra spaces at the end of each line.
When I run vim from tmux with TERM=xterm-256color vim, it behaves strangely.

Most terminals (like xterm) store the data which you can select on the screen. There's no hidden part behind it which tells the terminal that the application meant to fill in a background.

Applications update the screen by moving the cursor around, writing text (which may include actual spaces — or tabs which the terminal renders as spaces) and erasing parts of the screen.

Erasure is a special problem (for select/paste), since many terminals (such as xterm) will fill the erased area of the screen with the current color (the back color erase (bce) feature in the terminal description). But at the same time, erased areas no longer have characters stored in those positions of the screen. Terminals which use the on-screen representation will let you select everything except for the erased area. (As a special case, your terminal could have erased regions surrounded by text, which it will pretend are spaces for selection).

All of that's a nuisance, and long ago xterm provided a feature for ignoring the trailing spaces. Most other terminals don't provide that. And since it's an option, it may not be turned on if you happened to run xterm. Most terminal developers that copy xterm's features don't copy the options.

Going to tmux: it doesn't support the bce feature. Its developers decided not to. So normal applications running in tmux will produce trailing blanks. When you override the terminal description, it confuses tmux, since it doesn't know that vim is really assuming that the background will be cleared using the current color. You just get the erasure. No color.

On the other hand, GNU screen's developers decided a while back to support the feature. It's optional...

Trailing spaces when copying from console

Tags:

Vim

Terminal

Clipboard

Whitespace

Tmux

Related

Recent Posts