From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2004 invoked by alias); 14 Sep 2009 14:09:21 -0000 Received: (qmail 1996 invoked by uid 22791); 14 Sep 2009 14:09:21 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 14 Sep 2009 14:09:17 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 44FCB2BAB31; Mon, 14 Sep 2009 10:09:15 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3hjXr5v3CDLj; Mon, 14 Sep 2009 10:09:15 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 05E3A2BAB40; Mon, 14 Sep 2009 10:09:14 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 4F96CF589B; Mon, 14 Sep 2009 07:09:10 -0700 (PDT) Date: Mon, 14 Sep 2009 14:09:00 -0000 From: Joel Brobecker To: Marc Khouzam Cc: "gdb-patches@sourceware.org" Subject: Re: Another proposal for frontends and queries. Message-ID: <20090914140910.GD8327@adacore.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) 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: 2009-09/txt/msg00398.txt.bz2 > Another proposal that was thrown out there was to disable queries > when having started GDB with the MI interpreter. The idea is that > it would be frontends that would start GDB like that, and frontends > know what they are doing and don't need queries. > http://sourceware.org/ml/gdb/2009-07/msg00113.html > This seems too drastic to me. Isn't this is the approach that has always been taken in the past? I think that we should bite the bullet and implement this approach. The only issue, really, is how to detect that situation from the FE so that it can itself ask the user for confirmation before it sends the command... Or perhaps, another approach is to return an error (like it probably does now) that the frontend detect, and then provide a switch for that command to force the execution of that command despite the reported consequences. -- Joel