# Tell Documenter where symbols are imported from

**URL:** https://discourse.julialang.org/t/tell-documenter-where-symbols-are-imported-from/124081
**Category:** General Usage
**Created:** [December 22, 2024, 1:48am UTC](https://discourse.julialang.org/t/tell-documenter-where-symbols-are-imported-from/124081 "2024-12-22T01:48:08Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![jlapeyre](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jlapeyre/32/4514_2.png) [@jlapeyre](https://discourse.julialang.org/u/jlapeyre)
#### Post date: [December 22, 2024, 1:48am UTC](https://discourse.julialang.org/t/tell-documenter-where-symbols-are-imported-from/124081/1 "2024-12-22T01:48:08Z")

</div>

I want to organize my modules so that, among other things, when a user does `import MainMod.A` at the REPL, and then `A.[TAB]` they see to the extent possible, only symbols in the API. So I want to put the ugly code and the pretty code in modules with ugly names and then import only the pretty function names to an API module with a pretty name.

I want Documenter to show only the pretty path to the symbol. But it seems to always show the name of the module where the doc string is defined.

For example:

modA.jl

```julia
module A

import .._A: foo

end # module A

```

mod\_A.jl

```julia
module _A
"""
    foo()

The foo function does things.
"""
foo() = _foo_helper()

_foo_helper() = 1
end # module _A

```

- Is there a facility in `Documenter` to support this?
- If not, Is there a trick to do it?
- I’d still want a link to the API code in the ugly module; not a link to the line that imports into the pretty module. This would be more complicated.
- I can move the doc strings to the pretty module (I’m pretty sure). I can even move the functions in the API to the pretty module along with the doc string. The latter would then work fine with Documenter. This might be a good solution sometimes. But having doc strings close to the code, and API functions close to helper functions, is sometimes preferable.