Repository: microsoft/terminal (language: cpp)

Issue:
Selected block is copied as one line into clipboard
### Windows Terminal version

1.17.1023

### Windows build number

10.0.19045.2728

### Other Software

Far or any other TUI (mc, gdb etc.)

### Steps to reproduce

- Get the latest OpenConsole, either from the latest published WT package (1.17.2301.23004) or the latest source (e.g. ea44375f6dcdfb3c8bdf05b2f02e38a72d2dde09)
- Get [Far](https://farmanager.com/download.php?l=en), any version will do.
- Run OpenConsole, run Far in it
- Alt-Space, Properties, uncheck "Enable line wrapping selection", OK
- Alt-Space, Edit, Mark
- Select an arbitrary part of the buffer, Enter
- Paste the copied text somewhere, e.g. into Notepad.

### Expected Behavior

The block shape is preserved: clipboard contains text split into multiple lines

### Actual Behavior

The block shape is lost, clipboard contains text as one huge line without any line breaks

### More
- It works as expected in Windows 10 conhost (10.0.19041.2546).
- It works as expected in cmd.exe, so, supposedly, it has something to do with how the app writes the output.
- Commenting this line "fixes" it:
https://github.com/microsoft/terminal/blob/ea44375f6dcdfb3c8bdf05b2f02e38a72d2dde09/src/buffer/out/textBuffer.cpp#L1854
- Taking into account "wrapping state" etc. probably makes sense when the whole rows are selected:
![image](https://user-images.githubusercontent.com/11453922/230973149-2270d7f9-5983-4f40-bd4d-ab601b1bceeb.png)
   but if the user selects and copies an obvious "block", not even connected to the edges:
![image](https://user-images.githubusercontent.com/11453922/230973181-f1539b32-eb33-4152-9f8d-98c144df18e3.png)
it probably should be copied as a block unconditionally.



Discussion / hints:
@lhecker wanted to rewrite this area using the `GetText()` API. So he'll handle it as a part of that.
I also noticed FAR renders incredibly slow when run inside OpenConsole.
That's news to us!
@michalnpl Have you set `UseDx` to `DWORD` 2 under `HKEY_CURRENT_USER\Console` yet? This would enable AtlasEngine inside OpenConsole. But even with the standard GDI renderer it shouldn't run _that_ slow... 🤔
@DHowett and @lhecker, no, I have not been messing around with the registry. On vanilla main and the latest Windows 10, I get like a ~100 ms delay between pressing a key and a render when using CascadiaPackage, and sometimes you can see incomplete frames (like VSYNC is off). I've been using FAR for ages and have never seen something like this. I'll try to capture it in some format where it is visible.
Apologies if this is a stupid question--or rude; I don't intend it to be--but are you running a Debug or Release build? 😁 
> Apologies if this is a stupid question--or rude; I don't intend it to be--but are you running a Debug or Release build? 😁

Debug :) Lety me try Release...
> > Apologies if this is a stupid question--or rude; I don't intend it to be--but are you running a Debug or Release build? 😁
> 
> Debug :) Let me try Release...

Mystery solved. The release runs with no visible delay. Apologies for the false alarm ;)

============================================

On a separate note. I understand how Release is so much faster, but I was wondering why Debug renders incomplete frames anyway. Is VSYNC off by default on DWM (Desktop Window Manager)? Or am I having no idea what I am talking about? For reference, on Debug, on OpenConsole running Far, I can see this effect with the naked eye:

![image](https://github.com/microsoft/terminal/assets/25628581/11fbe3ce-7d48-41c5-85c9-9af973efa36f)

![image](https://github.com/microsoft/terminal/assets/25628581/91747bbe-5dfc-4196-9450-6723136284ba)

@michalnpl mind starting a [new Discussion](https://github.com/microsoft/terminal/discussions/new/choose) about that? This thread probably isn't the right place for that. Could be a couple reasons, but I don't want to cross-pollute the thread too much ☺️ 
@zadjii-msft @lhecker @DHowett  Sure, sorry for that.
@michalnpl no worries! I want to make sure your thought about FAR perf & VSYNC doesn't get lost whenever we get around to fixing this bug ☺️ 
Frankly, the `TextBuffer::GetText` function is pretty gnarly. 😄 It has sort of "infected" a dozen functions with its peculiar way of doing things so making any progressive improvements is difficult. [^1] On the other hand, the immediate bug fix is quite trivial, so I'll make a separate PR for that. This regressed in a1f42e87a8f7670a405f9df38ee1803db76fc516 btw.

[^1]: It uses a vector of vectors to represent text, and a pair of vectors of vectors to represent foreground/background colors. When copying plain text, it'll then concatenate the text vector-vectors. It'd be better to just do that right away. Was it done because one might need RTF/HTML text too? The functions that format the vector-vectors are also in `TextBuffer` and now need to parse the vector-vectors to figure out color changes anyways. Creating those vector-vectors is not cheap either. Just iterating over the buffer directly in GenHTML/RTF would be simpler. The redundant logic for handling block vs. line selection can be abstracted away via templates instead.

Fix patch:
diff --git a/src/interactivity/win32/Clipboard.cpp b/src/interactivity/win32/Clipboard.cpp
index 55909fdb962..1be0b11f2d7 100644
--- a/src/interactivity/win32/Clipboard.cpp
+++ b/src/interactivity/win32/Clipboard.cpp
@@ -251,7 +251,8 @@ void Clipboard::StoreSelectionToClipboard(const bool copyFormatting)
     const auto text = buffer.GetText(includeCRLF,
                                      trimTrailingWhitespace,
                                      selectionRects,
-                                     GetAttributeColors);
+                                     GetAttributeColors,
+                                     selection.IsKeyboardMarkSelection());
 
     CopyTextToSystemClipboard(text, copyFormatting);
 }


Test patch: