Remove inner module function name with @docs in Documenter.jl

Hi Guys, :slightly_smiling_face:

I’m creating documentation for a package using Documenter.jl :man_teacher:t2: :woman_teacher:t2:, and I’m loving the efficiency that the @docs macro provides. :raised_hands:t2:
However, in trying to make my documentation as user friendly as possible, I’ve hit a snag.

When I add this to my markdown file:

` ` `@docs
MyPackage.b
` ` `

the function syntax text that gets published in the respective html file looks like this:

MyPackage.B.b —Function

where the source docstring is, when instead I want it to look like this:

MyPackage.b —Function

As I want users of my package to call MyPackage.b(), or just b(), is there a way to exclude the inner module name (B) using Documenter? :thinking:

I’ve played around with the main package module, trying to @reexport the function b from B to MyPackage directly, but as the original docstring belongs to a function (b) in the inner module B, it doesn’t solve my problem. :man_shrugging:t2:

If it’s any help, the main package module looks something like this:

module MyPackage
export b

include("./B.jl")
using .B: b
end

If anyone can offer a solution, I would be soooooo grateful :pray:t2: :pray:t2: :pray:t2: :blush:

Thanks!
M

1 Like

Documenter is reflecting the situation accurately, i.e. that b is a function in module MyPackage.B. If you want the binding to belong to MyPackage directly, you should define it there. For example, you could organize the code as follows:

module MyPackage
  function b end
  module B
    import ..MyPackage: b
    # methods of b, including their docstrings, can live here
  end
end

Although I don’t know the exact case, I have a hunch that if you want b to be in the top level, then having B as a separate module is probably redundant and is creating unnecessary complexity. So the best solution might be to get rid of B altogether.

1 Like

Thanks @mortenpi .

So the best solution might be to get rid of B altogether.

That’s what I thought, but unfortunately isn’t really feasible in my situation.
Thanks again :slightly_smiling_face: