[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tabstop width not reset by reset command, or hardcoded to wrong widt

From: Thomas Dickey
Subject: Re: Tabstop width not reset by reset command, or hardcoded to wrong width
Date: Sun, 26 May 2019 06:54:46 -0400
User-agent: Mutt/1.5.23 (2014-03-12)

On Sun, May 26, 2019 at 11:21:00AM +0545, Vincent Huisman wrote:
> On 26-05-2019 01:02, Thomas Dickey wrote:
> >I rewrote the chunk, dropping the comment, and the result will be in today's
> >updates.
> That looks good, but the check for (init_tabs != 8) on currently line 448 is
> still there, so resetting most default terminals still won't reset the

hmm - actually the place to fix that would be prior to the tab-stops

Back to the documentation:


        If the terminal has hardware tabs which
        are initially set every n spaces when the terminal is powered  up,  the
        numeric  parameter  it  is given, showing the number of spaces the tabs
        are set to.  This is normally used by the  tset  command  to  determine
        whether  to set the mode for hardware tab expansion, and whether to set
        the tab stops.  If the terminal has tab stops that can be saved in non-
        volatile  memory,  the  terminfo  description  can assume that they are
        properly set.

Offhand, using hard-resets in rs1/rs2 would reinforce that assumption,
and eliminate the overhead of constructing tab-stops to make "it" match
the user's expectations.  You see, the documentation says that "it" matches
the power-up behavior.  It doesn't tell ncurses to initialize it to that

The one example with "it" to a value other than 8 is interesting, in part
because it won't work as documented above since it lacks the set/clear
capabilities for tab stops.  (If the entry were for something that people
_use_, I'd investigate and fix, but since the system's defunct, it's only
of academic interest).

> tabwidth on them if it's been changed intentionally or otherwise. I think
> that part of the check should be dropped, I can't find any valid/logical
> reason for it in the code.
> Sincerely,
> Vincent Huisman

Thomas E. Dickey <address@hidden>

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]