[Issue 6017] std.algorithm.remove has a wrong link
https://issues.dlang.org/show_bug.cgi?id=6017 hst...@quickfur.ath.cx changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #20 from hst...@quickfur.ath.cx --- Fixed in git HEAD (as currently shown on dlang.org under the Phobos prerelease section). --
[Issue 6017] std.algorithm.remove has a wrong link
https://issues.dlang.org/show_bug.cgi?id=6017 Brad Anderson e...@gnuk.net changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #14 from Brad Anderson e...@gnuk.net --- *** Issue 11575 has been marked as a duplicate of this issue. *** --
[Issue 6017] std.algorithm.remove has a wrong link
https://issues.dlang.org/show_bug.cgi?id=6017 --- Comment #15 from hst...@quickfur.ath.cx --- Has the dlang.org docs been updated to document $DDOC_ANCHOR? --
[Issue 6017] std.algorithm.remove has a wrong link
https://issues.dlang.org/show_bug.cgi?id=6017 --- Comment #16 from hst...@quickfur.ath.cx --- Pull 1174 does *not* fix the problem, unfortunately. :-( Struct members still show up as global names rather than qualified with the containing struct name. --
[Issue 6017] std.algorithm.remove has a wrong link
https://issues.dlang.org/show_bug.cgi?id=6017 --- Comment #17 from hst...@quickfur.ath.cx --- Correction: pull 1174 fixes the problem for non-template members, but members of template structs, etc., still show up as top-level symbols. --
[Issue 6017] std.algorithm.remove has a wrong link
https://issues.dlang.org/show_bug.cgi?id=6017 --- Comment #18 from hst...@quickfur.ath.cx --- I've found the reason: emitAnchorName() is unable to find the parent symbol of a template member because the .parent pointer is only set when semantic is run, but at the time of ddoc generation, the template may not even be instantiated yet, so all the .parent pointers of the member DSymbol's are NULL. --
[Issue 6017] std.algorithm.remove has a wrong link
https://issues.dlang.org/show_bug.cgi?id=6017 --- Comment #19 from hst...@quickfur.ath.cx --- Found the fix: https://github.com/D-Programming-Language/dmd/pull/3693 Unfortunately, it seems to be unrelated to the specific issue in this bug; see instead: issue #10366. --
[Issue 6017] std.algorithm.remove has a wrong link
https://issues.dlang.org/show_bug.cgi?id=6017 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Hardware|Other |All OS|Windows |All --- Comment #13 from Andrej Mitrovic andrej.mitrov...@gmail.com --- This seems to be fixed locally thanks to https://github.com/D-Programming-Language/dmd/pull/1174 and the updated 'MYREF' macro in std.algorithm, but the changes are not yet synced with the server, it currently points to: http://dlang.org/phobos/std_algorithm.html#remove Instead of: http://dlang.org/phobos/std_algorithm.html#.remove --
[Issue 6017] std.algorithm.remove has a wrong link
http://d.puremagic.com/issues/show_bug.cgi?id=6017 --- Comment #12 from Brad Anderson e...@gnuk.net 2012-03-11 15:15:42 PDT --- Adam D. Ruppe has a pull request that includes a fix for this. https://github.com/D-Programming-Language/dmd/pull/770 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6017] std.algorithm.remove has a wrong link
http://d.puremagic.com/issues/show_bug.cgi?id=6017 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||e...@gnuk.net --- Comment #11 from Jonathan M Davis jmdavisp...@gmx.com 2012-01-01 15:36:08 PST --- *** Issue 7195 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6017] std.algorithm.remove has a wrong link
http://d.puremagic.com/issues/show_bug.cgi?id=6017 kenn...@gmail.com changed: What|Removed |Added CC||kenn...@gmail.com --- Comment #1 from kenn...@gmail.com 2011-05-16 08:19:59 PDT --- It's not technically wrong as the enum value's name is really 'EditOp.remove'... Perhaps those enum values shouldn't be linked. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6017] std.algorithm.remove has a wrong link
http://d.puremagic.com/issues/show_bug.cgi?id=6017 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #2 from Jonathan M Davis jmdavisp...@gmx.com 2011-05-16 08:37:43 PDT --- The way that ddoc generates links needs to be completely rewritten. It needs to be hierarchal, but it's not at all. It acts like it's just linking in a set of free functions, and I believe that it links in the first symbol with a particular name, so if you have multiple documented symbols with the same name, then it's always the first one which gets linked in, regardless of whether that's the one which would be most usefully linked. I do think that having EditOp.remove linked is of value. But the links should be arranged in such a way that their hierarchy is clear, which would mean that the link would clearly be associated with EditOp and that the remove function would have its own link. I believe that this is really a fundamental ddoc problem and not a website problem at all. And I think that the table tha std.algorithm has now is as close to a fix as you're going to get any time soon. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6017] std.algorithm.remove has a wrong link
http://d.puremagic.com/issues/show_bug.cgi?id=6017 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #3 from Vladimir Panteleev thecybersha...@gmail.com 2011-05-16 10:29:58 PDT --- Wouldn't the problem be solved simpler by forcing it to generate unique anchor names for identifiers? I'm not sure how to understand Jonathan's comment about this, but I don't think DDoc actually thinks the two removes are the same identifier. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6017] std.algorithm.remove has a wrong link
http://d.puremagic.com/issues/show_bug.cgi?id=6017 --- Comment #4 from Jonathan M Davis jmdavisp...@gmx.com 2011-05-16 10:39:26 PDT --- Ddoc always generates a link to the first identifier with a given name. How it does that, I don't know. But it makes no attempt to make the links represent any kind of hierarchy. They're purely based on the base names of identifiers and completely ignore whether a particular identifier is actually an enum value or a member of a class or struct. It's designed as if everything were a free function. The way that the links are generated is far too simplistic and needs to be redesigned. In this case, both an enum value and a function have the same name. The enum happens to be first on the page, so it gets the link. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6017] std.algorithm.remove has a wrong link
http://d.puremagic.com/issues/show_bug.cgi?id=6017 --- Comment #5 from Vladimir Panteleev thecybersha...@gmail.com 2011-05-16 10:40:49 PDT --- My suggestion was to simply give one of them the anchor name remove_2, or something like that. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6017] std.algorithm.remove has a wrong link
http://d.puremagic.com/issues/show_bug.cgi?id=6017 --- Comment #6 from Jonathan M Davis jmdavisp...@gmx.com 2011-05-16 10:52:51 PDT --- They do need unique anchor names, but those anchor names should probably include the hiercharchy in some manner rather than simply having numbers tagged onto them - e.g. #EditOp__remove and #remove. The core problem is that ddoc doesn't care about anything other than the base identifier name. It makes no attempt to worry about the hiercharchy or about duplicate names. And honestly, it shouldn't have to worry about duplicate names, because duplicate names are illegal in the actual code. The duplication occurs because it's effectively treating all of the identifiers as if they were at module-level. Regardless, unique anchor names will be necessary. But I don't think that simply tacking on numbers is the right way to go about it. The fundamental problem needs to be solved. If you want to see a really bad example of the problem, looke at std.datetime. Several structs in there have the same function name, and the links become pretty useless. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6017] std.algorithm.remove has a wrong link
http://d.puremagic.com/issues/show_bug.cgi?id=6017 --- Comment #7 from Vladimir Panteleev thecybersha...@gmail.com 2011-05-16 10:56:42 PDT --- Yeah, I never said that this is a GOOD solution, but it's a quick and dirty one, and it'll allow linking to stuff in StackOverflow answers until someone fixes it properly ;) Several structs in there have the same function name, and the links become pretty useless. Hmm, so what should be done about this? Serialize the function signature into the anchor name? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6017] std.algorithm.remove has a wrong link
http://d.puremagic.com/issues/show_bug.cgi?id=6017 --- Comment #9 from Vladimir Panteleev thecybersha...@gmail.com 2011-05-16 11:17:40 PDT --- __ makes some sense since it's unlikely to ever be the case that you'll end up with underscores at the beginning and/or end of identifiers such that You can put periods in anchor names (MediaWiki uses them to escape other characters, for example), so there's no need for underscores. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6017] std.algorithm.remove has a wrong link
http://d.puremagic.com/issues/show_bug.cgi?id=6017 --- Comment #10 from Jonathan M Davis jmdavisp...@gmx.com 2011-05-16 11:24:05 PDT --- Ah. I didn't know that. I wrongly assumed that it wouldn't. That solves the problem quite nicely then. The obvious solution is then to represent the hiearchy directly. So, remove gets the anchor #EditOp.remove. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
