To all: I'd like to apologize for my negative tone and imprecision in my
points. Thanks for the discussion and the effort you put into these systems.
> On Aug 9, 2020, at 12:35 PM, Duncan Murdoch <murdoch.dun...@gmail.com> wrote:
>
> On 09/08/2020 3:15 p.m., Ben Bolker wrote:
>> On 8/9/20 3:08 PM, Duncan Murdoch wrote:
>>> On 09/08/2020 2:59 p.m., John Mount wrote:
>>>> Firstly: thanks to Ben for the help/fix.
>>>>
>>>> I know nobody asked, but.
>>>>
>>>> Having to guess where the documentation is just to refer to it is
>>>> just going to be really brittle going forward. Previous: if the
>>>> function you referred to existed in the package you were fine.
>>>
>>> That's not correct. The system could often work around the error, but
>>> not always.
>> I may be missing something. It may well be that referring to a
>> cross-package link by alias rather than by the name of the Rd page
>> actually never worked, but: would there be a big barrier to making
>> cross-package documentation links be able to follow aliases? I can
>> imagine there may be technical hurdles but it seems like a well-defined
>> problem ...
>
> To link to "?utils::dump.frames", you need to construct a URL that leads to
> the HTML file containing that help page on static builds of the help system.
>
> If utils is available, no problem, just look up the fact that the page you
> want is debugger.html at the time you construct the link. But it was
> documented that such links should work even if the target package was not
> available at the time the link was being made. So you need a link that you
> are sure will be available when the referenced package is eventually
> installed. Obviously that's going to be brittle.
>
> Perhaps the new requirement that referenced packages be mentioned in the
> DESCRIPTION file is a step towards addressing this. If everything that's
> referenced is present when the help system is being built, there will be an
> easy solution.
>
> Nowadays, it would probably be reasonable to put in stub pages for every
> alias, so that when you try to load dump.frames.html, the page itself
> redirects you to debugger.html. Or maybe you could just have a single page
> in each package that handles aliases via Javascript.
>
> Or R could just no longer support static copies of the help system.
>
> When you are using dynamically generated help pages, the link can be resolved
> by the server, and that's why those links have appeared to work for so long,
> even though the requirement to link to the filename instead of the alias has
> been there since before I wrote the dynamic help server.
>
> Duncan Murdoch
>
>>>
>>> Duncan Murdoch
>>>
>>>
>>> Future: if don't correctly specify where the help is you are wrong.
>>> Going forward: reorganizing a package's help can break referring
>>> packages. This sort of brittleness is going to be a big time-waster
>>> going forward. It seems like really the wrong direction in packaging,
>>> isolation, and separation of concerns (SOLID style principles).
>>>>
>>>>> On Aug 9, 2020, at 11:04 AM, Ben Bolker <bbol...@gmail.com> wrote:
>>>>>
>>>>> This might have to be \link[utils:debugger]{dump.frames} now, i.e.
>>>>> explicitly linking to the man page on which dump.frames is found
>>>>> rather than following aliases?
>>>>>
>>>>> On Sun, Aug 9, 2020 at 2:01 PM John Mount <jmo...@win-vector.com>
>>>>> wrote:
>>>>>>
>>>>>> With "R Under development (unstable) (2020-07-05 r78784)" (Windows)
>>>>>> documentation references such as "\link[utils]{dump.frames}"
>>>>>> trigger "Non-file package-anchored link(s) in documentation object"
>>>>>> warnings even if the package is in your "Imports."
>>>>>>
>>>>>> Is that not the right form? Is there any way to fix this other than
>>>>>> the workaround of just removing links from the documentation? I
>>>>>> kind of don't want to do that as the links were there to help the
>>>>>> user.
>>>>>>
>>>>>> ______________________________________________
>>>>>> R-package-devel@r-project.org mailing list
>>>>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>>
>>>> ______________________________________________
>>>> R-package-devel@r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>>
>>>
>
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
