From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119689 invoked by alias); 17 Feb 2019 15:34: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 119675 invoked by uid 89); 17 Feb 2019 15:34:24 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: gateway31.websitewelcome.com Received: from gateway31.websitewelcome.com (HELO gateway31.websitewelcome.com) (192.185.143.40) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 17 Feb 2019 15:34:23 +0000 Received: from cm14.websitewelcome.com (cm14.websitewelcome.com [100.42.49.7]) by gateway31.websitewelcome.com (Postfix) with ESMTP id BDDC8358CA for ; Sun, 17 Feb 2019 09:34:21 -0600 (CST) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id vOSTgoEMK2qH7vOSTgLQer; Sun, 17 Feb 2019 09:34:21 -0600 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=0rb5A+ryOI/oDommmc9L9nMlzPjglwFUeRDec8wVfbk=; b=IbinPd2StPCEkcZJPWwzurVr2g ZQVlnAnDFhPzFXXyMcjVWFtBwvAIkBDSNOoQj2Y+pPN5z3QWnlpEUg/LGn5CGgs7pbTPLaS8Py4as CdigOTkeFmwT5B7js9AaM1QbZ; Received: from 75-166-72-210.hlrn.qwest.net ([75.166.72.210]:60338 helo=bapiya) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gvOST-003PLz-Ft; Sun, 17 Feb 2019 09:34:21 -0600 From: Tom Tromey To: Joel Brobecker Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [RFC] Fix pager bugs with style output References: <20190209183721.3486-1-tom@tromey.com> <20190210123813.GA31881@adacore.com> <87k1i47tpx.fsf@tromey.com> <20190217123121.GB8537@adacore.com> Date: Sun, 17 Feb 2019 15:34:00 -0000 In-Reply-To: <20190217123121.GB8537@adacore.com> (Joel Brobecker's message of "Sun, 17 Feb 2019 16:31:21 +0400") Message-ID: <871s46mnsz.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2019-02/txt/msg00272.txt.bz2 >>>>> "Joel" == Joel Brobecker writes: Joel> One thought, perhaps: Would it make sense to call can_emit_style_escape Joel> inside emit_style_escape? I'm not entirely sure whether this would Joel> always work or not. On the one hand, the issue with relying on callers Joel> of emit_style_escape to verify that it makes sense is that we're bound Joel> to forget again in the future. On the other hand, I'm trying to think Joel> what would happen is a user changed XTERM from xterm to dump, for Joel> instance. Normally, we should always be in the normal style when the Joel> user has the prompt, so there would be no need to reset it back to Joel> the default style. One thing I did notice is that a couple of calls Joel> to emit_style_escape are unprotected in prompt_for_continue: From Joel> what I can tell, it seems like we'd be emitting ansi sequences when Joel> in fact we shouldn't? This is all more subtle than I would like :( The call to emit_style_escape in set_output_style deliberately does not pass the stream argument. But, it does test can_emit_style_escape on the stream. Changing this causes regressions because now the output won't end up in the wrap buffer. I added a comment to set_output_style. The calls to in prompt_for_continue do indeed need protection now that the caching is gone. I've fixed these. Also they were emitting to the wrap buffer, which seems wrong (at least for the first one), because the wrap buffer isn't flushed here. There are still mysteries in here to me, too, like why one call to prompt_for_continue checks "filter" but the other does not. Tom