1

I found an VSCode extension "Align spaces" and one displaying "elastic tabstops" which could be quite useful. It stretches the character's displayed column width visually like a tab character of dynamic width so that operators behind it appear vertically aligned without modifying the file content. It would prevent alignment formatting effort and create smaller diffs and files, how it ideally should be.

Big problem: the cursor does strange horizontal jumps when moving between lines because it moves based on the character's actual start column in the text. It doesn't know about the visual presentation.

Related problem: the same happens with multi-line selections. When doing a vertical (or rectangular) text selection, the cursor will not move visually correct but only at existing character locations.

Related SO question: Aligning multiline edit cursors

The question's mentioned extension solution is not good. It inserts whitespaces when unnecessary. It neither enables the aligned selection to simply move arround.

Microsoft's Visual Code doesn't have this problem because it can select text based on visual location alone even though a selected location doesn't contain a character. Only when a character is written, the file is actually modified and empty space is filled up as needed with indentation + alignment to write the character at the selection.

Still better though: ignore written characters for selected empty location.

I'd like to know if it is possible for a VSCode extension to let the cursor move independent of underlying text and only based on actually displayed column-row-coordinates. The cursor position then points either at empty locations or maps to a potentially multi-column displayed single character which could be split automatically if a character is written while a multi-column displayed character is selected after the starting column.

Does such an VSCode extension even exist?

rioV8
  • 24,506
  • 3
  • 32
  • 49
ChrisoLosoph
  • 459
  • 4
  • 8
  • The solution may be simpler: an extension could let the newline/end-of-file character span a high number of columns. All characters with N columns display width are counted as if they would occupy N columns instead of one. Hard tabs already work that way, it should be possible for non-tab characters too. For usuability, a possibility makes sense to position the cursor in between the displayed columns of a multi-column character/hard tab. – ChrisoLosoph Dec 28 '21 at 14:08

0 Answers0