Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Isn't it too large?



Looks like almost a full line in between. Should be 25% of a line or so. 
What do you all think?


Andrei

ag0aep6g <anonymous example.com> writes:

On 23.04.2016 21:43, Andrei Alexandrescu wrote:



 Looks like almost a full line in between.

It is a full line (<br><br>).

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 04/23/2016 03:50 PM, ag0aep6g wrote:
 On 23.04.2016 21:43, Andrei Alexandrescu wrote:




 Looks like almost a full line in between.

 It is a full line (<br><br>).

Should we use a single <br>? -- Andrei

ag0aep6g <anonymous example.com> writes:

On 23.04.2016 21:53, Andrei Alexandrescu wrote:
 Should we use a single <br>? -- Andrei

That would look better in the case you linked, but it would be a step 
back with longer signatures. E.g.

Adam D. Ruppe <destructionator gmail.com> writes:

On Saturday, 23 April 2016 at 20:06:39 UTC, ag0aep6g wrote:
 On 23.04.2016 21:53, Andrei Alexandrescu wrote:
 Should we use a single <br>? -- Andrei

 That would look better in the case you linked, but it would be 
 a step back with longer signatures. E.g.


I still can't get over the ridiculous grey constraints. WTF.

But what we could do is add a margin-bottom to them if needed, 
while keeping the others hugged up.

BTW this is what it looks like on my docs: 
http://dpldocs.info/experimental-docs/std.algorithm.searching.endsWith.4.html

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 04/23/2016 04:50 PM, Adam D. Ruppe wrote:
 On Saturday, 23 April 2016 at 20:06:39 UTC, ag0aep6g wrote:
 On 23.04.2016 21:53, Andrei Alexandrescu wrote:
 Should we use a single <br>? -- Andrei

 That would look better in the case you linked, but it would be a step
 back with longer signatures. E.g.


 I still can't get over the ridiculous grey constraints. WTF.

 But what we could do is add a margin-bottom to them if needed, while
 keeping the others hugged up.

 BTW this is what it looks like on my docs:
 http://dpldocs.info/experimental-docs/std.algorithm.searching.endsWith.4.html

Not bad! -- Andrei

default0 <Kevin.Labschek gmx.de> writes:

On Saturday, 23 April 2016 at 20:50:31 UTC, Adam D. Ruppe wrote:
 On Saturday, 23 April 2016 at 20:06:39 UTC, ag0aep6g wrote:
 On 23.04.2016 21:53, Andrei Alexandrescu wrote:
 Should we use a single <br>? -- Andrei

 That would look better in the case you linked, but it would be 
 a step back with longer signatures. E.g.


 I still can't get over the ridiculous grey constraints. WTF.

 But what we could do is add a margin-bottom to them if needed, 
 while keeping the others hugged up.

 BTW this is what it looks like on my docs: 
 http://dpldocs.info/experimental-docs/std.algorithm.searching.endsWith.4.html

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.

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

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 and 
being able to actually read constraints and having a better 
overview (via the toggling of the full signature) with function 
overloads alone are huge selling points, not to mention it does 
not try to cram the documentation for whole modules on a single 
page but splits it nicely into single pages for functions etc.

Adam D. Ruppe <destructionator gmail.com> writes:

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

Nick Treleaven <ntrel-pub mybtinternet.com> writes:

On Saturday, 23 April 2016 at 20:50:31 UTC, Adam D. Ruppe wrote:
 I still can't get over the ridiculous grey constraints. WTF.

It's much better reading signatures than before.

 But what we could do is add a margin-bottom to them if needed, 
 while keeping the others hugged up.

Good idea, probably only template symbols with constraints need 
the vertical whitespace.

 BTW this is what it looks like on my docs: 
 http://dpldocs.info/experimental-docs/std.algorithm.searching.endsWith.4.html

I found it a bit confusing at first. There should be 
expand/collapse buttons for overload details so you can compare 
them simultaneously. The current behaviour can still be kept too. 
I think template args should not be elided completely in the 
summary, at least (...) should be shown in the signature.

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

Adam D. Ruppe <destructionator gmail.com> writes:

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.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 04/23/2016 04:06 PM, ag0aep6g wrote:
 On 23.04.2016 21:53, Andrei Alexandrescu wrote:
 Should we use a single <br>? -- Andrei

 That would look better in the case you linked, but it would be a step
 back with longer signatures. E.g.


Good point. How about a controlled 1.25 lines spacing? -- Andrei

Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:

On Saturday, 23 April 2016 at 19:53:38 UTC, Andrei Alexandrescu 
wrote:
 On 04/23/2016 03:50 PM, ag0aep6g wrote:
 On 23.04.2016 21:43, Andrei Alexandrescu wrote:


 Looks like almost a full line in between.

 It is a full line (<br><br>).

 Should we use a single <br>? -- Andrei

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?

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

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