The clipboard finally remembers the shape of the cut.
VS Code's current Basic Editing documentation says that a column selection copied as rows A, B, and C can be pasted at one cursor in spread mode. The rows land on successive destination lines at the same visible column. The editor pads short destination lines or short copied rows with ordinary spaces when alignment needs it.[1]
Set editor.multiCursorPaste to full and the same clipboard content becomes one ordinary multiline insertion. At multiple cursors, VS Code distributes rows only when the row count matches the cursor count. Otherwise it pastes the complete block at each cursor.[1]
The setting chooses a contract. Spread preserves row-to-row alignment. Full preserves the literal multiline payload.
Visible column is the hard part.
A source offset is not always a screen column. VS Code lets each file use spaces or tabs, and its indentation detector can override the default tab size for the open document.[2] That means a paste operation has to respect the destination's layout state. Counting bytes or JavaScript string positions is not enough.
Unicode adds another trap. UAX #29 defines grapheme clusters as a practical approximation of user-perceived characters. One visible character can contain several code points, so splitting text at an arbitrary code-point or code-unit boundary can break the thing the user sees as one character.[3]
Width is contextual too. UAX #11 classifies characters for narrow and wide behavior, but it warns that the East Asian Width property is not an off-the-shelf width algorithm for modern terminal emulators. Font choice, layout, variation sequences, and application tailoring can change what occupies a cell or visual advance.[4]
Use four fixtures before changing the setting.
Start with equal ASCII lines so you can confirm the basic route. Then paste into ragged lines, including one shorter than the target column. Add tabs before and after the cursor. Finish with combining marks, emoji sequences, and wide characters. Compare the rendered result, not a string-length counter.
Run the same clipboard through spread and full. Undo between trials. If your team shares editor settings, save the chosen behavior in the workspace only after the fixture matches the editing job. A table-shaped payload may want spread. A literal code block may want full.
Do not clone the editor with a six-line snippet.
The press below is a teaching tool for plain ASCII. It shows row distribution, padding, destination insertion, and the difference between spread and full. It warns when tabs or non-ASCII text enter the fixture because it does not own the editor's font metrics, grapheme tailoring, or tab model.
That boundary is intentional. The browser demo helps you predict the simple case. Your installed editor, current font, indentation settings, and real file remain the test bench for layout-sensitive text.