From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10580 invoked by alias); 14 Aug 2008 19:42:08 -0000 Received: (qmail 10567 invoked by uid 22791); 14 Aug 2008 19:42:07 -0000 X-Spam-Check-By: sourceware.org Received: from igw3.br.ibm.com (HELO igw3.br.ibm.com) (32.104.18.26) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 14 Aug 2008 19:41:25 +0000 Received: from mailhub1.br.ibm.com (unknown [9.18.232.109]) by igw3.br.ibm.com (Postfix) with ESMTP id 07BCB390114 for ; Thu, 14 Aug 2008 16:21:38 -0300 (BRST) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by mailhub1.br.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m7EJdd361917152 for ; Thu, 14 Aug 2008 16:41:11 -0300 Received: from d24av02.br.ibm.com (loopback [127.0.0.1]) by d24av02.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m7EJd9Hf007545 for ; Thu, 14 Aug 2008 16:39:09 -0300 Received: from [9.18.238.102] (dyn531835.br.ibm.com [9.18.238.102]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m7EJd9mD005202; Thu, 14 Aug 2008 16:39:09 -0300 Subject: Re: Fix python indented multi-line commands From: Thiago Jung Bauermann To: Eli Zaretskii Cc: gdb-patches@sources.redhat.com, drow@false.org In-Reply-To: References: <1218686123.8263.18.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 14 Aug 2008 19:42:00 -0000 Message-Id: <1218742708.554.0.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit 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: 2008-08/txt/msg00379.txt.bz2 On Thu, 2008-08-14 at 22:20 +0300, Eli Zaretskii wrote: > > From: Thiago Jung Bauermann > > Cc: gdb-patches@sources.redhat.com, Daniel Jacobowitz > > Date: Thu, 14 Aug 2008 00:55:23 -0300 > > > > > Please don't call variables by mysterious names such as > > > "special_processing". Please give that variable a meaningful name > > > that would explain the purpose of this flag even without reading the > > > code of the callers of this function. > > > > I agree. The argument has two effects though (stripping of leading > > whitespace, and recognizing GDB control commands), so I had some > > difficulty in finding a meaningful name for it. That's why I left it > > with that one. It is now called parse_input, what do you think? > > "parse_commands"? Or maybe "only_end_cmd" (and reverse the tests)? parse_commands is good. Do we have a deal? :-) -- []'s Thiago Jung Bauermann IBM Linux Technology Center