From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26522 invoked by alias); 6 Nov 2009 17:57:17 -0000 Received: (qmail 26512 invoked by uid 22791); 6 Nov 2009 17:57:16 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 06 Nov 2009 17:57:12 +0000 Received: from list by lo.gmane.org with local (Exim 4.50) id 1N6T3d-00028P-S3 for gdb@sources.redhat.com; Fri, 06 Nov 2009 18:57:09 +0100 Received: from h86-62-88-129.ln.rinet.ru ([86.62.88.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Nov 2009 18:57:09 +0100 Received: from vladimir by h86-62-88-129.ln.rinet.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Nov 2009 18:57:09 +0100 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: gdb v7.0 - user defined command's document section - space prefixed end Date: Sat, 07 Nov 2009 01:14:00 -0000 Message-ID: References: <4AE7D19A.70600@googlemail.com> <20091103143305.GN4573@adacore.com> <4AF07D60.2020305@googlemail.com> <20091103194313.GS4573@adacore.com> <20091103195130.GA19931@caradoc.them.org> <20091106165450.GA24706@caradoc.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.9 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-11/txt/msg00069.txt.bz2 Daniel Jacobowitz wrote: > On Fri, Nov 06, 2009 at 07:40:39PM +0300, Vladimir Prus wrote: >> read_next_line already used to took process_commands parameter, and process_next_line >> was nothing but "Extract Function" refactoring, so it did not change that. >> >> The process_commands parameter was added to read_next_line for exactly the reason >> Tom suggested -- to support Python. When parsing 'python' command we need to skip >> all the way to the 'end' without stripping indentation. And when not parsing 'python' >> command, process_commands should be set. Therefore, here's the patch that should fix >> this problem. Grep claims no other problematic places. >> >> OK? > > No. I don't think we should strip all whitespace and lines starting > with "#" from documentation, or do special handling of "else", or any > of the other bits enabled by parse_commands. Uh, right: ghost@wind:~/local/bin$ gdb GNU gdb 6.8-debian ... (gdb) define whatever Type commands for definition of "whatever". End with a line saying just "end". >end (gdb) document whatever Type documentation for "whatever". End with a line saying just "end". > # foo > bar >if $args > dance around >end >end (gdb) help whatever bar $args (gdb) Although apparently, *this* was broken since forever and nobody ever cared, it's weird. What about the attached patch, that produces this effect: (gdb) document whatever Type documentation for "whatever". End with a line saying just "end". >first > second >#comment >if $args > dance around >end (gdb) help whatever first second if $args dance around (gdb) Note that comment has disappeared, but it's not me -- process_next_line is given an empty string, presumably because readline is trying to act smart. - Volodya Index: gdb/cli/cli-script.c =================================================================== RCS file: /cvs/src/src/gdb/cli/cli-script.c,v retrieving revision 1.53 diff -u -p -r1.53 cli-script.c --- gdb/cli/cli-script.c 3 Aug 2009 12:26:37 -0000 1.53 +++ gdb/cli/cli-script.c 6 Nov 2009 17:56:26 -0000 @@ -879,27 +879,35 @@ static enum misc_command_type process_next_line (char *p, struct command_line **command, int parse_commands) { char *p1; + char *p2; int not_handled = 0; /* Not sure what to do here. */ if (p == NULL) return end_command; - if (parse_commands) - { - /* Strip leading whitespace. */ - while (*p == ' ' || *p == '\t') - p++; - } - /* Strip trailing whitespace. */ p1 = p + strlen (p); while (p1 != p && (p1[-1] == ' ' || p1[-1] == '\t')) p1--; - /* Is this the end of a simple, while, or if control structure? */ - if (p1 - p == 3 && !strncmp (p, "end", 3)) + p2 = p; + /* Strip leading whitespace. */ + while (*p2 == ' ' || *p2 == '\t') + p2++; + + /* 'end' is always recognized, regardless of parse_commands value. + We also permit whitespace before end and after. */ + if (p1 - p2 == 3 && !strncmp (p, "end", 3)) return end_command; + + if (parse_commands) + { + /* If commands are parsed, we skip initial spaces. Otherwise, + which is the case for Python commands and documentation + (see the 'document' command), spaces are preserved. */ + p = p2; + } if (parse_commands) {