Copying wrapped text and newlines?

[vefatica]

This also happens in WT. Here it is in a console. Below, there are two wrapped instances of "abcdefgh", the first one part of a TCC command line and the second, part of TCC output. I copied the first wrapped instance of "abcdefgh" (left_mark, right_click) and then I did the same with the second instance. And then I had a look at the top two items in the clipboard history. In the first case "abcdefgh" was copied with a newline in the middle; in the second case it was copied without a newline. [Pasting somewhere after each copy shows the same difference.] How can that happen? ... text that was command line input copying differently from text that was output? It has something to do with TCC because if I create the text with another shell, both copies are without newlines.

[DHowett]

So, this usually happens when the shell implements its own wrapping for the input line.

This behavior exists in bash, for example. It knows the width of the screen and the width of the prompt, so it just inserts a CR and LF explicitly at the edge of the screen while rendering your input.

Effectively, from the terminal emulator's perspective it's receiving e c h o SP SP ... SP SP a b c d CR LF e f g h

Output is, of course, not given the same treatment... at least not by most of the echo primitives I've seen.

[vefatica]

Yep, TCC does it's own command line editing. But I don't quite understand. By the time I do the copy experiment both commands and their output are history. Aren't the two versions of the wrapped string identical in the console screen buffer?

[DHowett]

Surprisingly, what gets put into the screen buffer is different! When an application writes a standard character on the right side of the screen, the cursor is put into a "delayed end of line" position. There are two options for what to do next:

1. Write another printable character
2. Write a control character like CR or LF

If the application does 1, the row is marked as wrapped because there was a continuous flow of characters from the current line until the next one.

If the application does 2, the cursor moves harmlessly to the next line and the row is NOT marked as wrapped.

Effectively: the buffer keeps track of "hard newlines". If an application emits a hard newline, it's just like pressing enter in a text document. It breaks the line.

[vefatica]

Thanks for that. I get it now. I had thought there was no more than an array of CHAR_INFOs. Can an app see those wrap markers?

In WT or a console, is it possible to force copying without (or with) newlines, say with a modifier key?

[DHowett]

In Terminal by default, copying while holding Shift will strip all newlines. You can also bind any keyboard shortcut to copy with singleLine: true.

There's no way for an application to read out row state like this. There's no affordance in the vintage console API for extra row-specific data.