Duplicate of #1020 and see explanations there. It's certainly not about referring to 80 columns, behaviour is the same with any terminal width. It's about compatibilty. Should it be changed, it might break other software, so the fact that it is astonishing behaviour indeed does not necessarily imply it should be "fixed". Please also consider that there does not seem to be any terminal around that would handle this differently, for the reasons mentioned. If the Go system has a problem with that it's a Go bug, please report it there as they may be ignoring established terminal behaviour or making invalid assumptions about it.

Lol... The funny thing is, I rewrote the issue description 3-4 times before submitting, and at least 2 of those started with how I regretted this would be a breaking change. (I eventually decided the issue report was to point out the issue, without waxing on about possible solutions.)

First off, this is not an issue with go: Go is simply generating tab delimited output to indicate columns without respect to an output device. The number or width of those columns is beside the point.

Secondly, xterm compatibility is an important feature, and should not be compromised. (I do think a settings option may be warranted, however.)

Thirdly, while the cause is the same, I think this is a distinct issue from #1020:

• The horizontal in "horizontal tab" is pertinent, and I see no reason HT should advance to the next line:
  • If the cursor is already at the right column, I see no problem with a zero-width tab character.
• (Except for xterm compatibility) I see no reason the 80th column should be treated specially.
  • Would it make sense to offer a settings option to extend HT behaviour past the 80th column. (Perhaps this option has a side-effect of snapping the window width to multiples of 8 characters? Then again we have the "Principle of least astonishment"... The devil's always in the details... isn't it?)

Whether this is distinct from 1020 (which I doubt) or not could be discussed if you upload a piece of text (screen log, which can be catted to the terminal) to demonstrate an issue, and also describe how you imagine it would be better.
Anyway, for me the point is indeed compatibility, or compliance with a de-facto standard, and this is not only about xterm.
I tried a vast set of major terminals this morning, gnome-terminal, lxterminal, urxvt, vte, st, and even Powershell Windows Terminal, and they all behave the same. So observing this I see no case to change anything, even though everyone agrees this is weird, sorry.

I completely agree that compatibility trumps all... I mentioned xterm solely because you did, but we agree it needs to behave the same as mainstream terminals.

"Distinct from" can mean different things. In this case I was referring to the effects of

• having gaping "line-wrap like" spaces on the right side of the window, before a single character in the last column

being distinct from

• having tabs in the last column being zero-width,

not their cause, which likely is shared.

The next time I'm in a non-proprietary go project with tests, I'll post a dump of the test output for your review. but I don't know if this will happen this week. I will point out that both less and Windows PowerShell displays the content in the manner I would expect

Because I value backwards compatibility, that is why I suggested a configuration option to treat the first 80 columns specially (as is the current, compatible, behavior)... The non-compatible behavior would be to not treat the left 80 columns as the only screen-region with tab stops.

I understand, at this time, that we're simply just discussing options.

Windows PowerShell displays the content in the manner I would expect

I'm not sure what exactly you are complaining about in this issue, but I do know there was a bug in the tab handling in the Windows console, which is quite likely still present if you're using an older version of Windows 10 (like pre Windows 11). So just be aware that what you're seeing there is probably not the way the Windows console works anymore, and may not be a great example to use as something that matches your expected behavior.

Here is a file (In this case, from go test, but it's just a simple tab delimited file) demonstrating the issue I reported.
mintty_issue.go_test_output.txt

This file is simply a patch against project Jarcoal's httpmock package for golang on GitHub to give the output above. (I had to make the package's pathname long enough to produce HTs past column 80): httpmock_long_pkg_path.diff.txt

UPDATE:
I can confirm that this does not reproduce the problem by itself... there must be some modal component with it... I'll update this ticket when I know more.

UPDATE2:
I also confirm that running reset at the terminal resolves this, so it is indeed modal. Still it would be helpful to know what mode is being set on the terminal to more easily diagnose similar problems in the future.

There is an issue with TAB when output in the "pending wrap" state, i.e. after the last column - the line will wrap on the next character but the TAB will be skipped. Output your example file at terminal width 89 to see it.
Again, same behaviour in xterm, but xterm has an optional workaround for it, see xterm manual page option -cu for more information. If that is your issue, I will consider a similar option.

I'm still investigating this intermittently, but it appears to be an interaction between my bash shell prompt and window resizing the window... I'll include my prompt string here for reference, but I haven't exactly identified the issue exactly yet.

export PS1='\[\e]0;\u@\h: \w\a\]${debian_chroot: ($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '

I will post again when I know more.

Released 3.6.3.