From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
cc: Robert Haas <robertmhaas@gmail.com>, Christoph Berg <myon@debian.org>,
        PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: pgsql: Add basic TAP tests for psql's tab-completion logic.
In-reply-to: 
 <CAH2-Wzk3xfc53A0KZRe4Xu9TALRU=HSfSVZqx3jBuws08mG-ew@mail.gmail.com>
References: <20200103170226.GB32629@msg.df7cb.de>
 <26339.1578072930@sss.pgh.pa.us> <20200103174839.GD32629@msg.df7cb.de>
 <CA+TgmoZsPe_G1ssO6KVPqbMQHDEz=vHPQH1jxaSjpG_QxM7wUg@mail.gmail.com>
 <CAH2-WznPzfWHu8PQwv1Qjpf4wQVPaaWpoO5NunFz9zsYKB4uJA@mail.gmail.com>
 <22669.1578104202@sss.pgh.pa.us>
 <CAH2-WznyU3QxzRr12W_tJAzjwM9qd6bh_ZGx3Xupk3RqE1t72A@mail.gmail.com>
 <25298.1578106280@sss.pgh.pa.us>
 <CAH2-Wzkq4OELzn3yZvuqsPuso5JfSXdaD+yW=1VMz2YpXTBYxA@mail.gmail.com>
 <CAH2-Wzk3xfc53A0KZRe4Xu9TALRU=HSfSVZqx3jBuws08mG-ew@mail.gmail.com>
Comments: In-reply-to Peter Geoghegan <pg@bowt.ie>
	message dated "Fri, 03 Jan 2020 19:28:55 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3054.1578115809.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sat, 04 Jan 2020 00:30:09 -0500
Message-ID: <3055.1578115809@sss.pgh.pa.us>
Precedence: bulk

Peter Geoghegan <pg@bowt.ie> writes:
> On Fri, Jan 3, 2020 at 7:06 PM Peter Geoghegan <pg@bowt.ie> wrote:
>> No. Also tried setting PG_COLOR=3D"off" and CLICOLOR=3D0 -- that also
>> didn't help. (This was based on possibly-relevant vars that "env"
>> showed were set).

Yeah, that's not terribly surprising, because if I'm reading those
escape sequences correctly they're not about color.  They seem to be
just cursor movement and line clearing, according to [1].

What I'm mystified by is why your copy of libreadline is choosing to
do that, rather than just space over to where the word should be printed
which is what every other copy seems to be doing.  I have a fresh new
Debian installation at hand, with

$ dpkg -l | grep readline
ii  libreadline-dev:amd64                 7.0-5                           =
     amd64        GNU readline and history libraries, development files
ii  libreadline5:amd64                    5.2+dfsg-3+b13                  =
     amd64        GNU readline and history libraries, run-time libraries
ii  libreadline7:amd64                    7.0-5                           =
     amd64        GNU readline and history libraries, run-time libraries
ii  readline-common                       7.0-5                           =
     all          GNU readline and history libraries, common files

and I'm not seeing the failure on it, either with TERM=3Dxterm
or with TERM=3Dxterm-256color.  So what's the missing ingredient?

> Removing the single check_completion() test from 010_tab_completion.pl
> that actually fails on my system ("offer multiple table choices")
> fixes the problem for me -- everything else passes.
> I suppose that this means that the problem is in "offer multiple table
> choices" specifically.

I'd hate to conclude that we can't test any completion behavior that
involves offering a list.

If we can't coerce libreadline into being less avant-garde in its
screen management, I suppose we could write a regex to recognize
xterm escape sequences and ignore those.  But I'd be happier about
this if I could reproduce the behavior.  I don't like the feeling
that there's something going on here that I don't understand.

BTW, it seems somewhat likely that this is less about libreadline
than about its dependency libtinfo.  On my machine that's from

ii  libtinfo6:amd64                       6.1+20181013-2+deb10u2          =
     amd64        shared low-level terminfo library for terminal handling

what about yours?

			regards, tom lane

[1] https://www.xfree86.org/current/ctlseqs.html