From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32100 invoked by alias); 5 Dec 2012 19:11:34 -0000 Received: (qmail 32090 invoked by uid 22791); 5 Dec 2012 19:11:33 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 05 Dec 2012 19:11:24 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qB5JBM1k012103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Dec 2012 14:11:22 -0500 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id qB5JBLYJ029536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 5 Dec 2012 14:11:21 -0500 From: Tom Tromey To: Eli Zaretskii Cc: Phil Muldoon , gdb-patches@sourceware.org Subject: Re: [patch][python] 5 of 5 - Frame filter documentation changes References: <50B8C35F.9040000@redhat.com> <83boeet4wh.fsf@gnu.org> Date: Wed, 05 Dec 2012 19:11:00 -0000 In-Reply-To: <83boeet4wh.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 01 Dec 2012 12:58:54 +0200") Message-ID: <87boe8s49y.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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 X-SW-Source: 2012-12/txt/msg00089.txt.bz2 >>>>> "Eli" == Eli Zaretskii writes: Eli> So in CLI, each filter can be enabled and disabled individually, but Eli> in MI they can only be enabled en masse, and cannot be disabled? is Eli> that a good idea? In MI it is fine. It is no extra effort for an MI client to request unfiltered output on each invocation it cares to. The reason for the enablement command for MI is just so that clients don't get filtered output without expecting it. This would work ok -- the output is backward compatible -- but could be surprising to users. An MI client could disable filters individually. The commands are always there. Tom