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

[Vladimir Prus <vladimir@codesourcery.com>]

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)
     {