-
Notifications
You must be signed in to change notification settings - Fork 119
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
:browse feature request #688
Comments
Good idea. Currently we have properties separated into their own subheading in the Can we have |
When I write a module I always mark properties as private. |
I made a pull request that implements this. Basically now each existing section has a nested sub-sections classifying things in various ways (e.g., public/private, imported from somewhere, or defined at the REPL). The output looks like this:
|
@yav, can we close this issue? |
Yep, should be done. |
Thanks @yav ! |
In the current
:browse
, no distinction is made between the public and private members of the currently loaded module. I think it would be nice to see this distinction, specifically to know what functions/properties a module exports.The text was updated successfully, but these errors were encountered: