www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Line spacing for '///ditto' on the website

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Isn't it too large?

http://dlang.org/phobos/std_experimental_allocator_building_blocks_affix_allocator.html#.AffixAllocator.goodAllocSize

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


Andrei
Apr 23 2016
parent reply ag0aep6g <anonymous example.com> writes:
On 23.04.2016 21:43, Andrei Alexandrescu wrote:
 http://dlang.org/phobos/std_experimental_allocator_building_blocks_affix_allocator.html#.AffixAllocator.goodAllocSize


 Looks like almost a full line in between.
It is a full line (<br><br>).
Apr 23 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 04/23/2016 03:50 PM, ag0aep6g wrote:
 On 23.04.2016 21:43, Andrei Alexandrescu wrote:
 http://dlang.org/phobos/std_experimental_allocator_building_blocks_affix_allocator.html#.AffixAllocator.goodAllocSize



 Looks like almost a full line in between.
It is a full line (<br><br>).
Should we use a single <br>? -- Andrei
Apr 23 2016
next sibling parent reply 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. http://dlang.org/phobos/std_algorithm_searching.html#.endsWith
Apr 23 2016
next sibling parent reply 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. http://dlang.org/phobos/std_algorithm_searching.html#.endsWith
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
Apr 23 2016
next sibling parent 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. http://dlang.org/phobos/std_algorithm_searching.html#.endsWith
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
Apr 23 2016
prev sibling next sibling parent reply 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. http://dlang.org/phobos/std_algorithm_searching.html#.endsWith
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.
Apr 24 2016
parent 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
Apr 26 2016
prev sibling parent reply 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))
Apr 24 2016
parent 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.
Apr 26 2016
prev sibling parent 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. http://dlang.org/phobos/std_algorithm_searching.html#.endsWith
Good point. How about a controlled 1.25 lines spacing? -- Andrei
Apr 23 2016
prev sibling parent reply 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:
 http://dlang.org/phobos/std_experimental_allocator_building_blocks_affix_allocator.html#.AffixAllocator.goodAllocSize

 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?
Apr 24 2016
parent 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
Apr 24 2016