From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9173 invoked by alias); 3 Jul 2009 08:33:53 -0000 Received: (qmail 9164 invoked by uid 22791); 3 Jul 2009 08:33:53 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.25) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 03 Jul 2009 08:33:42 +0000 Received: from totara (188.30.255.123.dynamic.snap.net.nz [123.255.30.188]) by viper.snap.net.nz (Postfix) with ESMTP id 4EFF03DA6A9; Fri, 3 Jul 2009 20:33:39 +1200 (NZST) Received: by totara (Postfix, from userid 1000) id 77C5DC14D; Fri, 3 Jul 2009 20:33:37 +1200 (NZST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19021.49761.460467.374394@totara.tehura.co.nz> Date: Fri, 03 Jul 2009 08:33:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: [mi] -stack-list-arguments --simple-values In-Reply-To: References: <200906301339.30711.vladimir@codesourcery.com> <19020.32725.55167.391078@totara.tehura.co.nz> From: nickrob@snap.net.nz (Nick Roberts) X-IsSubscribed: yes 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-07/txt/msg00088.txt.bz2 > > One reason why, in Emacs, we don't fully parse MI output, but use regular > > expression matching, is because of these inconsistencies. > > Can you clarify this? KDevelop does use a parser and convert MI into > a convenient internal representation, so it is clearly possible in C++. > I don't know much about Emacs internals -- is there some problem with > parsing methods available there? We're just starting to fully use MI in Emacs and formally parse (Dmitry) the output but I would think it's possible parse anything in Emacs (Lisp) and it's just a question of complexity. > > > People often lament the poor syntax of MI but it really needs a plan to > > replace it with something better. However, such a plan would really need a > > maintainer to lead it and doesn't really work on a Write After Approval basis. > > FWIW, both the above issue is universally believed to be not good, so > patches to introduce MI3 version and switch select commands to "right" > syntax appear to be fairly simple. I quite like the idea of incrementally changing the output with new commands because as soon as MI3 is released, you can be sure people will find shortcomings with that. You could say it is a more agile approach. -- Nick http://www.inet.net.nz/~nickrob