On 04/24/2016 08:28 AM, Joseph Rushton Wakeling wrote:
> The use of hardcoded <br> tags in ddoc output is a bit odd -- surely it
> would be better to encode the list of symbols as entries in an
> unnumbered list, and use CSS to style its layout as wished?

Great idea - could you please work on a PR to introduce that? -- Andrei

On Sunday, 24 April 2016 at 07:56:07 UTC, default0 wrote:
> Only thing I dislike about it is that the "Overload: <short signature>" thing of the currently selected overload vanishes completely, instead of just changing color to suggest it is the active one you selected.

Try it now:

http://dpldocs.info/experimental-docs/std.algorithm.searching.endsWith.2.html

> Also, your search currently does not list modules as search results (try searching base64, it will only show things like the Base64/Base64Impl things etc).

Huh, good catch! I split identifiers on snake_name and camelCase for partial matches, but never split module names on dots.


It is rebuilding its index now, you should see new results pretty soon. (The slow thing about it right now is I have to rebuild docs package-at-a-time for interlinking and nav, and I have to rebuild EVERYTHING for the search index. Before going beta and taking public packages to add to the docs, I need to make the regeneration incremental as it takes a while now.)

> Anyhow I really should be using your docs by now, seems the timeframe where you hit a "this has not been implemented yet, sorry"-warning on half the links you click on is finally over

Aliases and single variable enums still have bugs in the generator (`alias a = b;` works, but `alias b a;` doesn't, and it thinks `enum a = 0;` is the same as `auto a = 0;`), but yeah, most everything else works now. I am also in the process of switching syntax away from Phobos' ad-hoc macros over to my new convenient things, so pages are still changing but most of them should be legible now.

I'm still short of my major goals of rewritten content and heavy interlinking - it can only automatically link names from the same module right now (it parses imports but doesn't analyze them at this point), but indeed, I think it is a huge step up from the main site.

This doc btw is describing my syntax changes:
http://dpldocs.info/experimental-docs/test.html

On Sunday, 24 April 2016 at 11:25:46 UTC, Nick Treleaven wrote:
> There should be expand/collapse buttons for overload details so you can compare them simultaneously.

That's not a bad idea, but I'm probably not going to do it just because it doesn't fit well with my plan of separate pages for each function - including overloads. On the separate pages, there may be completely different documentation, and even if the source says "///ditto", the generator does things like filter out params that don't exist on this overload.

So I'd suggest just opening in two browser windows instead and positioning them side-by-side....

It could also be done in Javascript. Maybe I will consider that later.

> I think template args should not be elided completely in the summary, at least (...) should be shown in the signature.

Yeah, I actually agree with that now, as long as they are constrained (hah) by the nowrap css rule, I think they are fine. I am going to see about adding them on the next version.

>
> I think there are too many line breaks, maybe this instead:
>
> Function endsWith -> bool @anyAttributes
> (alias pred, R)
> (R doesThisEnd)
> if (isInputRange!R &&
>     ifTestable!(typeof(doesThisEnd.front), unaryFun!pred))


The counterpoint to this is any page with complex individual arguments.

http://dpldocs.info/experimental-docs/simpledisplay.SimpleWindow.this.1.html

SimpleWindow's constructor has several parameters, most with default values. Take away the linebreaks there and it becomes an unreadable mess.

I don't have an example of long template arguments off the top of my head, but even cgi.d's main mixin starts to show it:

http://dpldocs.info/experimental-docs/arsd.cgi.CustomCgiMain.html

Since template arguments can have types and default values too (and specializers!), they can get really messy on one line as well.

So, putting them on one line really hurts those cases, and I don't think putting them on separate lines really hurts the easy cases (like endsWith, or std.math http://dpldocs.info/experimental-docs/std.math.cos.3.html it is a bit silly to break it down there, but it doesn't really /hurt/), I am erring on the side of using more space.

oh dear the table of contents there indeed is silly, I need to take that back out unless there's several headers.