Re: bin/56496: etcupdate(8) merge formatting issue

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR bin/56496; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/56496: etcupdate(8) merge formatting issue
Date: Wed, 17 Nov 2021 22:47:11 +0700

     Date:        Wed, 17 Nov 2021 15:10:01 +0000 (UTC)
     From:        Hauke Fath <hauke%Espresso.Rhein-Neckar.DE@localhost>
     Message-ID:  <20211117151001.AA3961A923A%mollari.NetBSD.org@localhost>
 
   |  On Wed, 17 Nov 2021 00:45:01 +0000 (UTC), RVP wrote:
   |  >  Do you see the same behaviour with another terminal emulator, or a newer
   |  >  version of xterm (370) ?
 
 I believe xterm is acting as it was designed (and has acted forever) - as
 poorly designed (or perhaps, just unexpectedly peculiar for modern usages)
 as this particular feature might be.
 
   |  Reproducible on an Aug 9 netbsd-9 build with modular X11; the xterm was
   |  built on Oct 6 and is version 368. The machine is updating pkgsrc as we
   |  speak.
 
 I doubt that checking different xterm versions will make any difference
 at all - testing other terminal emulators might be interesting (though
 many copy xterm in order to remain compatible).
 
 What is more relevant here is to discover what else is different between
 these versions, or perhaps, how you're testing them.   Something is causing
 the xterm tabs to be set in some cases, and not others.  Discovering what
 that is, and if appropriate, altering that, is about all that is left to
 discover about this PR (which clearly is not really about etcupdate, that
 just happens to be able to trigger the issue).
 
 And, from your more recent e-mail:
 
   | And on both the modular and the native xterm, the issue goes away when
   | issuing a reset(1) after the re-size - permanently, even after further
   | re-sizes, AFAICS.
 
 Not permanently, reset clears the xterm's programmed tabs settings, after
 which it treats \t as (to past the next multiple of 8 column number) as
 expected - which is independant of terminal width.
 
 But if something happens after which sets the tabs again, it will go back
 to operating as it has been doing.   This is how it is designed to work.
 
 So, see if you can work out what is setting the tabs in the cases where
 they're being set.   Something is.
 
 For that, the easiest way would be to use the printf test after stretching
 an xterm window, created in various different ways, and see which of them
 are affected.   If all, then it is likely something in the X resources.
 Otherwise, the difference in how they're created might reveal the source
 of the setting.
 
 kre