From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76820 invoked by alias); 10 Mar 2017 17:20:22 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 76803 invoked by uid 89); 10 Mar 2017 17:20:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=4.1 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,KAM_TK,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=vertical, H*f:sk:f263c39, terminal's, UD:tk X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 10 Mar 2017 17:20:20 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6691E85547 for ; Fri, 10 Mar 2017 17:20:21 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v2AHKKDk007722; Fri, 10 Mar 2017 12:20:20 -0500 Subject: Re: [pushed] Fix PR tui/21216: TUI line breaks regression To: Jan Kratochvil References: <1488932352-10885-3-git-send-email-palves@redhat.com> <20170309230359.GA503@host1.jankratochvil.net> <20170310125946.GA508@host1.jankratochvil.net> <20170310140450.GA5206@host1.jankratochvil.net> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <4593d5aa-00c7-75a9-9fc6-b65bddad0c0a@redhat.com> Date: Fri, 10 Mar 2017 17:20:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20170310140450.GA5206@host1.jankratochvil.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-03/txt/msg00137.txt.bz2 Fixing this properly is turning out to be much trickier than I expected. The main issue is that the TUI/ncurses updates/refreshes to the command window are done by drawing only what changed, using cursor movement. For example, with a small enough screen, we see: (gdb) PASS: gdb.tui/tui-nl-filtered-output.exp: set pagination on set height 2000 (gdb) PASS: gdb.tui/tui-nl-filtered-output.exp: set height 2000 printf "hello\nworld\n"printf "hello\nworld\n" hello world (gdb) FAIL: gdb.tui/tui-nl-filtered-output.exp: correct line breaks "2A" is move up two lines, "23D" is move left 23 lines, then print "printf "hello\nworld\n"", then "hello\nworld" then "K" to clear the line, and finally print the prompt. I tried to work around it by forcing empty commands in between commands, to force the screen to clear, but the "smart" refresh makes the output of that even harder to match. What you were seeing: (gdb) set pagination on (gdb) set height 2000 ... that's moving the cursor to the start of the line, and then clearing it, making room for the next command. I.e., both commands appeared on the same vertical coordinate on the screen, presumably because the command window only fitted one line or two. So in general, we can't just strip escape sequences. Maybe we could pull it off by implementing a virtual terminal that is aware of the escape sequences, understands the cursor movement, line clearing, etc., something like the un_ansi_vt procedure here: [handling of ANSI terminals using Expect] http://wiki.tcl.tk/9673 We'd send the test command to gdb, and feed gdb's output to that procedure in a loop, which builds an array of lines, and then check if the rendered command "screen" (an array of lines) had the command result we wanted. We'd need to match the virtual terminal's "bounding" with the command window's size. Ideally, we'd be able to force the exact size of command window we want, instead of inheriting that from the terminal dejagnu is running on. Or maybe do something different. Maybe dump the screen using scr_dump and compare to a dump previously saved. I'd need to investigate further. So while I think it'd be neat to do any of this, it's a lot more work and investigation than this new test is worth it. So for now, I'm going to simply remove it. Thanks, Pedro Alves