Skip to content

testing: leading spaces in Example output are dropped from godoc display #4487

Description

@rsc
If you write an example that generates a right-leaning triangle:

// Output:
//   *
//  **
// ***

Then it tests okay (I think the leading space is dropped from the target and the actual
output)
but it formats in the web godoc as:

*
 **
***

instead of

  *
 **
***

That is, godoc eats the leading spaces.

More generally I wonder if the comment processing in examples should be handed off to
the standard go/doc comment processing and formatting. It already handles stripping an
*equal* amount of indent from pre blocks.

Activity

  1. rsc commented on Dec 10, 2012

    @rsc
    ContributorAuthor

    Comment 1:

    Labels changed: added size-m.

  2. rsc commented on Dec 10, 2012

    @rsc
    ContributorAuthor

    Comment 2:

    Labels changed: added suggested.

  3. cespare commented on Jan 5, 2013

    @cespare
    Contributor

    Comment 3:

    This behavior is inherent to the Example parsing in go/doc -- it calls strings.TrimSpace
    on Output.
    This seems wrong to me not only for the purposes of displaying the Example but for
    testing as well. One might well construct a whitespace-sensitive example that doesn't
    fail as expected; for instance, the following actual outputs are accepted by the
    right-leaning triangle example output:
    *
     **
    ***
             *
     **
    ***
    The testing documentation isn't explicit about the behavior here. What if the output
    parsing were changed? Right now, doc.Examples removes all leading/trailing whitespace;
    what if instead it only removed /^[ ]*\n?/   ? I think that's a more intuitive behavior
    that works for both the single-line (e.g., '// Output: hi') and multi-line output
    targets.
    The trimming of the actual output would have to be adjusted correspondingly.
    I'm happy to make these changes but wanted some feedback first.
  4. cespare commented on Jan 5, 2013

    @cespare
    Contributor

    Comment 4:

    @rsc regarding your suggestion about handing off the comment processing -- is stripping
    equal whitespace from the front of the output block desirable?
  5. agl commented on Jan 6, 2013

    @agl
    Contributor

    Comment 5:

    I'm guessing that rsc intended to assign this to Andrew instead.

    Owner changed to @adg.

  6. rsc commented on Jan 6, 2013

    @rsc
    ContributorAuthor

    Comment 6:

    Indeed, sorry.
  7. cespare commented on Jan 6, 2013

    @cespare
    Contributor

    Comment 7:

    * Does an issue having an owner imply "don't work on this"?
    * According to http://swtch.com/~rsc/go11.html, the 'Suggested' label is "suggested for
    people looking for work"
    Thanks for the clarification; this is not covered in
    http://golang.org/doc/contribute.html.
  8. rsc commented on Jan 6, 2013

    @rsc
    ContributorAuthor

    Comment 8:

    Unless the issue status is Started or a comment by someone says
    they're working on it, then it's up for grabs. Thanks.
    Stripping equal whitespace seems fine and required. Otherwise you'd
    have to write
    //line1
    //line2
    instead of
    // line1
    // line2
  9. cespare commented on Jan 6, 2013

    @cespare
    Contributor

    Comment 9:

    Thanks Russ.
    Sorry I wasn't clear -- I was talking about pre block rule where any equal amount of
    leading whitespace is stripped.
    Removing the single space from the front is of course fine and is already taken care of
    by the normal comment parsing before doc.Examples gets to it.
  10. rsc commented on Jan 6, 2013

    @rsc
    ContributorAuthor

    Comment 10:

    Can you give an example? I'm surprised that normal comment parsing
    strips the space; otherwise how can it distinguish //foo from // foo?
  11. cespare commented on Jan 6, 2013

    @cespare
    Contributor

    Comment 11:

    This is what the docs for (*CommentGroup) Text() in go/ast indicate.
    "Comment markers (//, /*, and */), the first space of a line comment, and leading and
    trailing empty lines are removed."
    Here's an example: http://play.golang.org/p/PWA4tmcnOe
  12. adg commented on Jan 7, 2013

    @adg
    Contributor

    Comment 12:

    This is merely the result of some over-aggressive trimming. The fix is simple:
    https://golang.org/cl/7057048/

    Status changed to Started.

  13. adg commented on Jan 7, 2013

    @adg
    Contributor

    Comment 13:

    This issue was closed by revision a88bbbb.

    Status changed to Fixed.

  14. added this to the Go1.1 milestone on Apr 14, 2015
  15. locked and limited conversation to collaborators on Jun 24, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    FrozenDueToAgeSuggestedIssues that may be good for new contributors looking for work to do.

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions