From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105401 invoked by alias); 17 Jan 2019 21:01:32 -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 105384 invoked by uid 89); 17 Jan 2019 21:01:31 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=deliberately, H*r:user X-HELO: relay.fit.cvut.cz Received: from relay.fit.cvut.cz (HELO relay.fit.cvut.cz) (147.32.232.237) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 17 Jan 2019 21:01:28 +0000 Received: from imap.fit.cvut.cz (imap.fit.cvut.cz [147.32.232.238]) by relay.fit.cvut.cz (8.15.2/8.15.2) with ESMTPS id x0HL1MDt085146 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 17 Jan 2019 22:01:23 +0100 (CET) (envelope-from jan.vrany@fit.cvut.cz) Received: from sao (027906ee.bb.sky.com [2.121.6.238] (may be forged)) (authenticated bits=0 as user vranyj1) by imap.fit.cvut.cz (8.15.2/8.15.2) with ESMTPSA id x0HL1KLL061405 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 17 Jan 2019 22:01:21 +0100 (CET) (envelope-from jan.vrany@fit.cvut.cz) Message-ID: <4943920de5a6a09118288ec08cb328e945549f4a.camel@fit.cvut.cz> Subject: Re: [PATCH] MI: Add new command -complete From: Jan Vrany To: Tom Tromey Cc: gdb-patches@sourceware.org Date: Thu, 17 Jan 2019 21:01:00 -0000 In-Reply-To: <87imynm3ia.fsf@tromey.com> References: <20190103222930.4365-1-jan.vrany@fit.cvut.cz> <87imynm3ia.fsf@tromey.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.4-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-01/txt/msg00414.txt.bz2 On Thu, 2019-01-17 at 13:29 -0700, Tom Tromey wrote: > > > > > > "Jan" == Jan Vrany writes: > > Jan> This commit adds a new '-complete' MI command which is implemented using > Jan> CLI's 'complete'. > > I suspect it would be better to just write a new MI function and then > mildly refactor complete_command so that the two commands can share most > of their implementation. > > First, this would make it so we could add options to the MI command as > needed. (Perhaps the current argument to the command ought to have a > flag to avoid future parsing problems? What do you mean by this? Can you give an example? > I am not sure.) > > Second, it would mean that we could make changes to the CLI command > without worrying about breaking MI compatibility. As for changes to CLI command, I've got the impression from the code that the format is rather strict (from use of printf_unfiltered(), for instance), deliberately so to not break clients (Emacs is mentioned). Indeed, not really an argument against splitting. > > What do you think of this? I thought of that actually. Also, it'd make the MI interface more regular w.r.t quoting of spaces and other special characters. But in the end I could not find a way without duplicating enough code from the original function, so hacked it that way. Let me try harder :-) > > I looked and I see that some other MI commands are implemented directly > by CLI commands. I am not sure but I suspect this might be a deprecated > approach. Yeah, there's quite a lot of them. If it is a deprecated approach, I did not know. > > Jan> + bool is_mi_like = uiout->is_mi_like_p (); > > This could be removed by having a more explicit API. I'm sorry, I'm not sure what do you mean here. > > Jan> + ui_out_emit_list completions_emitter (uiout, "completions"); > Jan> + if (result.number_matches != 0) > Jan> + { > Jan> + if (result.number_matches == 1) > Jan> + { > Jan> + if (is_mi_like) > Jan> + uiout->field_fmt(NULL, "%s%s", arg_prefix.c_str (), > Jan> + result.match_list[0]); > Jan> + else > Jan> + printf_unfiltered ("%s%s\n", arg_prefix.c_str (), > Jan> + result.match_list[0]); > > Space before "(" in the field_fmt call. Unifying the cases would be > preferable. Or another argument for separation. > Thanks! Jan