Comment 1:

Maybe sorting is the wrong word and that what we should really do is group by root.

Comment 2:

FWIW this continues to bother me.  Grouping by root would be fine.  I'd be happen even
with two groups:
standard library $GOROOT first (bounded set, with short names), followed by all $GOPATHs
merged together and sorted (a huge set with longer names)

Comment 3:

Labels changed: added go1.1maybe.

Comment 5:

Labels changed: removed go1.1maybe.

Comment 6:

Labels changed: added godoc.

Comment 7:

As a new user of the language, starting to build up my own little library packages as I
build more complicated programs, and starting to look at packages written by third
parties, I definitely would like a way for godoc to show somewhat more clearly which
packages are "core" libraries and which are third party.
Being able to have the list-of-packages stay as a sidebar when viewing the individual
package godoc pages would also be a win -- at least as somebody new to the language and
libraries I find myself surfing around between the list of all packages and individual
packages a lot, as I figure out what's where.

Comment 8:

Issue #5784 has been merged into this issue.

Comment 9:

issue #5571 is related to this issue and may be solved with a unified solution. For
instance it would be possible to include three sections in the package listing, namely:
* Standard repositories
* Sub-repositories
* Third party repositories

Comment 10:

Sorry I meant issue #5561.

Comment 11:

If you have many non-standard packages installed, it gets unwieldy to navigate.
I would like standard packages and each part of GOPATH to have its own section, and also
be able to collapse/expand each level. This idea:
http://pkleiweg.home.xs4all.nl/go/godoc-demo.html

Comment 12:

Labels changed: added go1.3maybe.

Comment 13:

Labels changed: added release-none, removed go1.3maybe.

Comment 14:

Labels changed: added repo-tools.

@adg I'd like to add a practical observation. I find the headings misleading.

Currently, (go1.4.2), $GOPATH imports are alphabetically intermingled with packages from the standard library under a heading "Standard library". Further down the page there is a heading "Other packages" where I'd naturally expect my imports to be listed. It's not a clear structure.

I feel that separating Standard Library documentation from GOPATH would make more sense, but even if it's deemed not, the headings need to reflect the structure more accurately.

@paulswanson I agree that the gopath packages should be in a separate list to the standard library.

@adg, the more I use godoc the more it's ticking me off. What's required to move this forward? Is this one a question of consensus and / or implementation? Cheers.

It's an implementation thing.

It would be nice to have this worked on. A separation of Standard Library and GOPATH libraries would improve the godoc experience immensely.

Also, Merry Christmas and thank you for working on Go.

I will take a stab at it. I also like @pebbe's suggestion about collapsing/expanding items beyond a certain depth. Makes for a much cleaner UI.

I have brought it to a presentable state now. I have grouped them under 2 headers - Standard Library and Third Party, which are collapsible and expandable like in a package directory. This would make for a much more cleaner experience.

In collapsed form -

Expanding the third part section -

I will send a CL once the 1.11 tree opens.

When GOPATH has multiple parts, I would like to see each part have its own section

Hmm .. that is a bit non-trivial as it would involve more changes to the PageInfo struct to avoid looping multiple times through the DirList in the html template.

I think the current CL is a good start, and since the original issue was just about grouping it into GOROOT and GOPATH, its good to keep this to just that to avoid further complexity in the review.

Maybe it's best to tackle this in a separate issue.

Change https://golang.org/cl/95835 mentions this issue: godoc: group package home page list by root

Change https://golang.org/cl/101295 mentions this issue: godoc: cleanup package templates