From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13910 invoked by alias); 10 Mar 2017 18:17:25 -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 13849 invoked by uid 89); 10 Mar 2017 18:17:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=bringing, Thing, Hx-languages-length:1525, suggests 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 18:17:22 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (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 F3C5580F94 for ; Fri, 10 Mar 2017 18:17:22 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v2AIHLgp007259; Fri, 10 Mar 2017 13:17:22 -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> <4593d5aa-00c7-75a9-9fc6-b65bddad0c0a@redhat.com> <20170310172744.GA7009@host1.jankratochvil.net> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <4f9a4e59-ccc8-9d6e-7ce2-f030f6efe184@redhat.com> Date: Fri, 10 Mar 2017 18:17: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: <20170310172744.GA7009@host1.jankratochvil.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-03/txt/msg00142.txt.bz2 On 03/10/2017 05:27 PM, Jan Kratochvil wrote: > On Fri, 10 Mar 2017 18:20:18 +0100, Pedro Alves wrote: >> Or maybe do something different. > > Yes, I do know all these problems. This is why I was going to separate TUI > output to a different project (with its own non-TCL testsuite) along with > separating MI, and replacing it all by some sane RPC variant later. > https://git.jankratochvil.net/?p=gdbmicli.git;a=summary > How you love pulling things out of context. Bringing up the separation-into-processes issues again suggests you're thinking of testing at the core <-> TUI interface level. We could have that too, by writing a unit test. I thought of writing one that exercised the tui_file class. I may still write one. Thing is, this case calls for a black-box test, to make sure that final terminal output is how we intended. That's why I spent the effort to write the test, and more effort to try to preserve it. How TUI communicates with the core of the debugger is completely irrelevant here. Whatever testing you think would be appropriate for testing TUI/ncurses _output_ in your project, we can consider for GDB too. If you have ideas for that, please share them. > But you ditched that I didn't "ditch it". I explained to you, with detail, why in my opinion that wouldn't be a design we'd want. > and you were right, there are other debuggers which > already do it the right way. I don't think I ever said such a thing. Thanks, Pedro Alves