Tabstop width not reset by reset command, or hardcoded to wrong width

[Vincent Huisman]

I came across a bug report about tabs
http://lists.gnu.org/archive/html/bug-ncurses/2019-02/msg00021.html
but I can't reply to it because I wasn't on the list before now. I have 
experienced a similar issue https://bugs.gentoo.org/654644 and managed 
to fix it so that it works for me. Had I seen the thread on this list, 
it would have cost me less time.

Anyway, so I now have a custom terminal by changing init_tabs#4 in the 
existing terminal description, and saved it in ~/.terminfo. On every ssh 
to that box I set tabs 4 from .bashrc. Everything is working fine until 
I issue reset on that terminal. The tab width is reset back to 8, 
regardless of what's in .terminfo. Digging through the source I see that 
progs/reset_cmd.c hardcodes tabstops to 8 if init_tabs is not 8. Now 
when I run nano --tabsize 4, it sets the ncurses TABSIZE to 4 and 
ncurses uses the it#4 from the terminal definition. However, the 
terminal itself still thinks tabstops are 8 wide so the interface (and 
document) is all messed up similar to the tabs 4 it#8 case the original 
report was about. I'm not sure how many terminals are out there with 
it!=8 but ncurses is likely broken on all of them. This is all assuming 
hard tabs.

Small remark on the original bug thread:
> curses (SVr4 curses, ncurses, NetBSD)
> all provide a library variable TABSIZE which an application could set to
> reflect a tab-size which was set externally.  Otherwise, they all use the
> initial-tabs value from the terminal database.
I found that TABSIZE as well as init_tabs are used. In case 
TABSIZE!=init_tabs it is used to calculate where to place the cursor and 
that blows up when using hard tabs. I might be wrong, but this is my 
observation.

I'm not sure why reset explicitly ignores the init_tabs but looking at 
the code I get the feeling that the assumption is that most or all 
terminals have it#8 anyway, and a previously-issued tabs should persist 
across resets. I personally feel that tabs should be reset along with 
everything else. Also, resetting a borked terminal because of an 
accidental cat won't undo any damage done by a file containing a valid 
ct,st* sequence, so I'd say this is a proper bug.

Default terminal (linux):
$ tabs 4 > tab; cat abc
abc
        abc
$ cat tab; cat abc
abc
    abc
$ reset; cat abc
abc
    abc

Default terminal (linux) modified with it#4:
$ tabs 8; cat abc
abc
        abc
$ cat tab; cat abc
abc
    abc
$ reset; cat abc
abc
        abc

After both of these cases, nano is messed up. I fixed it for myself by 
using alias reset="reset; tabs 4" so I don't have any problem in 
whichever case, but a lot of people will be running the defaults and 
might not be able to properly reset their terminal.

Sincerely,

Vincent Huisman