Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

@autodocs: pages matches the suffix of all available files #2639

Open
pjaap opened this issue Feb 28, 2025 · 4 comments
Open

@autodocs: pages matches the suffix of all available files #2639

pjaap opened this issue Feb 28, 2025 · 4 comments

Comments

@pjaap
Copy link
Contributor

pjaap commented Feb 28, 2025

Hi there, I came across a weird @autodocs problem.

I have files foo.jl and bar_foo.jl in my src folder.

The snipped

```@autodocs
Modules = [Foo]
Private = true
Public = false
Pages = ["foo.jl"]
```

includes both foo.jl and bar_foo.jl for the documentation. I think this contradicts the documentation in https://documenter.juliadocs.org/stable/man/syntax/#@autodocs-block

@pjaap pjaap changed the title @autodocs: pages matches the suffix of all avalable files @autodocs: pages matches the suffix of all available files Feb 28, 2025
@mortenpi
Copy link
Member

mortenpi commented Mar 2, 2025

I don't disagree that the behavior can be considered a bit counter-intuitive, but I think it matches the docs?

In the above example docstrings from module Foo found in source files that end in a.jl and b.jl are included. The page order provided by Pages is also used to sort the docstrings. Note that page matching is done using the end of the provided strings and so a.jl will be matched by any source file that ends in a.jl, i.e. src/a.jl or src/foo/a.jl.

It's essentially an endswith check on the path.

@pjaap
Copy link
Contributor Author

pjaap commented Mar 3, 2025

Fair enough, it is indeed covered by the documentation. However, I think that it is a misleading feature, as I was puzzled by duplicated docs for similar file names. I took me a while to determine the Pages property to be the cause of the problem.

I would like to restrict this file lookup only to folder structures. However, this would break the current behavior.
At least we should include an example foo_a.jl in the docs.

What do you think?

@mortenpi
Copy link
Member

mortenpi commented Mar 5, 2025

Yea, always happy to take clarifying documentation 🙂

I think changing the behavior would indeed be breaking. I suppose one non-breaking way to do this would be to introduce a new options with a new name.

@pjaap
Copy link
Contributor Author

pjaap commented Mar 5, 2025

I rephrased that part in the doc in #2647. I agree that changing the behavior is a breaking change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants