TABs can confuse cursor placement?

[drj11]

The following is a fragment of a program that has run through go fmt, so the lines begin with true TAB (U+0009) characters.

        if i < len(vmet) {
            fmt.Sprintf("%s, vmtx, height, %d, tsb, %d", vmet[i].Advance, vmet[i].Tsb)
        }

i have no idea if the TAB characters will survive this transmission in the year 2023.

attempting to put the cursor near the end of the Sprintf line in fact draws the cursor at the screen top-left. for example, move to the beginning of the Sprintf line and use Shift-right or Ctrl-] to move to end of line.

For me, on an 80-column terminal, the cursor is blinking at the top-left and the screen contents are not redrawn.

[deadpixi]

Hmm...could you send me the file, or another file that triggers the issue? It's not happening for me.

[drj11]

i'm using kitty https://sw.kovidgoyal.net/kitty/ which i now realise may be relevant. [later: i also tried in Apple Terminal and got the same buggy behaviour; in my opinion Apple Terminal is likely to have a more diligent approach to its smart terminal implementation and TERMINFO record]

[drj11]

file is here: https://git.sr.ht/~drj/meti/tree/main/item/main.go

And attached main.go.zip

[later: oh wait i reformatted the file so that when shown in tine the lines are < 80 columns, but when shown with 8 SPACE TABS they are > 80 columns]

[drj11]

main.go-with-actual-long-lines.zip

This one has actual long lines (I joined them ^N). So for me, putting the cursor at the beginning of line 44 and pressing right-arrow until the cursor goes past the right-hand end of the 80 column terminal triggers the bug: the cursor sits at the Home [0 0] position, and the editor does not scroll to the right. If i keep pressing right-arrow then eventually it "catches up" and the window display is correct, but the cursor is still at Home.

Also, the scrolling of lines 44 and 47 is hilarious, because they have internal tabs, but differing numbers of characters preceding that tab. When the editor window scrolls right or left the tabs line up on window-oriented TAB boundaries.

[drj11]

Hmm, in the example immediately above, neither Ctrl-] nor Shift-Right behave oddly, contrary to my original report. Weird.