From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111191 invoked by alias); 7 Apr 2019 10:08:12 -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 111178 invoked by uid 89); 7 Apr 2019 10:08:12 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=eliz@gnu.org, U*eliz, elizgnuorg, executed X-HELO: mailsec118.isp.belgacom.be Received: from mailsec118.isp.belgacom.be (HELO mailsec118.isp.belgacom.be) (195.238.20.114) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 07 Apr 2019 10:08:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skynet.be; i=@skynet.be; q=dns/txt; s=securemail; t=1554631688; x=1586167688; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=6kMhML36D8k8XanCMtGTfsQV/QESb9x5IGPzLTA4yZ4=; b=daqCd8OdpJWxv3TaDRmWkmksX6773xy3g/vg3rm1GLRfJdb7JSPEd7vd R2E8axmnsYSfNx1NXstAr0t1Q9l+QA==; Received: from 212.135-131-109.adsl-dyn.isp.belgacom.be (HELO md) ([109.131.135.212]) by relay.skynet.be with ESMTP/TLS/AES256-GCM-SHA384; 07 Apr 2019 12:08:04 +0200 Message-ID: <1554631684.1854.17.camel@skynet.be> Subject: Re: Still some style problems with 8.3 branch From: Philippe Waroquiers To: Eli Zaretskii , Tom Tromey Cc: gdb-patches@sourceware.org Date: Sun, 07 Apr 2019 10:08:00 -0000 In-Reply-To: <83wokbc5lk.fsf@gnu.org> References: <1553942211.1854.2.camel@skynet.be> <835zrzi0d7.fsf@gnu.org> <83wokbc5lk.fsf@gnu.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-04/txt/msg00101.txt.bz2 I have just done some tests, comparing the behaviour of the 8.3 branch with and without the patch suggested by Eli. It works better with the patch, but even with the patch, I still encountered one case where the style was not the expected style after the continuation prompt. To reproduce (in a 80x24 terminal): ./gdb/gdb ./gdb/gdb break cli_ui_out::do_field_string run gdb/testsuite/outputs/gdb.ada/info_auto_lang/proc_in_ada   (gdb) b proc_in_c   (gdb) run info func error #### then type several times return at the page prompt. #### At some point in time, you see 0x00007ffff691d360  transaction clone for std::overflow_error::overflow_error(st --Type for more, q to quit, c to continue without paging-- d::__cxx11::basic_string, std::allocator > const&) And the line after the prompt is unexpectedly in black. This is both with and without the patch. Philippe On Wed, 2019-04-03 at 21:21 +0300, Eli Zaretskii wrote: > Ping! > > > Date: Sun, 31 Mar 2019 17:28:52 +0300 > > From: Eli Zaretskii > > CC: gdb-patches@sourceware.org > > > > > From: Philippe Waroquiers > > > Date: Sat, 30 Mar 2019 11:36:51 +0100 > > > > > > I just encountered a styling problem with the 8.3 branch > > > (also on the 8.4). > > > Test executed with GNU gdb (GDB) 8.2.91.20190330-git > > > > > > To reproduce: > > > ./gdb/gdb ./gdb/gdb > > > info sources > > > and then type return successively, to see each page. > > > After the initial page, the first line contains a file that > > > is partially printed in green color, partially printed in black color, > > > e.g., in the below given output. > > > The line that starts with '--Type ' is in black, as expected. > > > Then the next line starts in green as expected. > > > But only '/bd/home/ph' is in green. > > > We then have 'ilippe/gdb/git/relbranch/gdb/minsyms.h,' in black. > > > Then all is normal till the next page. > > > > > > So, that seems to point at some remaining problem in the > > > buffering/output of style/color codes. > > > > I don't think it's due to buffering. If I #ifdef away this part near > > the end of prompt_for_continue: > > > > /* Restore the current styling. */ > > if (can_emit_style_escape (gdb_stdout)) > > emit_style_escape (applied_style); > > > > then the problem seems to go away. So I think this style setting is > > what causes the problem, probably because applied_style has the wrong > > value here? The incorrect style seems to start precisely from the > > first character that exceeds the last column of a line, so I think > > it's indeed due to the above snippet. > > > > Tom, can you look into this, please? > >