Re: gdb v7.0 - user defined command's document section - space prefixed end

[Vladimir Prus <vladimir@codesourcery.com>]

Daniel Jacobowitz wrote:

> On Tue, Nov 03, 2009 at 11:43:13AM -0800, Joel Brobecker wrote:
>> > I noticed my scripts didn't work under v7.0 only when I saw this bug in
>> > launchpad. I guess I am not the only one who has indented "ends" this way
>> > :)
>> > https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/461594
>> 
>> If you could maybe help us a little bit, and track down the author
>> of the patch that introduced the change of behavior, and then ask
>> him whether the change was intended?
> 
> I believe it was:
> 
> 2009-08-03  Jim Ingham  <jingham@apple.com>
>             Vladimir Prus  <vladimir@codesourcery.com>
> 
>         Refactor reading of commands
> 
>         * defs.h (read_command_lines_1): Declare.
>         * cli/cli-script.c (read_next_line): Only return string,
>         do not process.
>         (process_next_line): New, extracted from read_next_line.
>         (recurse_read_control_structure): Take a function pointer to the
>         read function.
>         (get_command_line) Pass the read_next_line as reader function
>         into recurse_read_control_structure.
>         (read_command_lines_1): New, extracted from...
>         (read_command_lines): ...here.

I don't think that the patch associated to the above changelog entry
is directly responsible -- consider:

-      val = read_next_line (&next, current_cmd->control_type != python_control);
+      val = process_next_line (read_next_line_func (), &next, 
+                              current_cmd->control_type != python_control);

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?

- 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 16:40:12 -0000
@@ -1470,7 +1470,7 @@ document_command (char *comname, int fro
     error (_("Command \"%s\" is built-in."), comfull);

   sprintf (tmpbuf, "Type documentation for \"%s\".", comfull);
-  doclines = read_command_lines (tmpbuf, from_tty, 0);
+  doclines = read_command_lines (tmpbuf, from_tty, 1);

   if (c->doc)
     xfree (c->doc);