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

Feature request: index of all functions in assembly #431

Closed
rmunn opened this issue Mar 30, 2017 · 2 comments
Closed

Feature request: index of all functions in assembly #431

rmunn opened this issue Mar 30, 2017 · 2 comments

Comments

@rmunn
Copy link
Contributor

rmunn commented Mar 30, 2017

One of the things that I have often wished to have while reading through the API reference of various F# libraries is that there was an index of all functions in a given assembly, no matter what namespace or module those functions were found in. This is especially needed for FAKE, whose API docs badly need an index. The best tool to create such an index is, of course, FSharp.Formatting, the same tool that created those API docs in the first place.

What I'd like to see in a function index is:

  1. All public functions in the namespace are listed in the index, in alphabetical order.
  2. Function names are sorted case-insensitively. (In the invariant culture, so that running a build that includes FSharp.Formatting will always produce the same index file no matter what culture the build server is located in.)
  3. All function names starting with the same base letter (i.e., after NFKD decomposition and stripping any diacritics), case-insensitively, will be grouped into one section. I.e., the functions allWidgets, AdvancedQuark and ÅngströmToMeter would all be grouped into section A. Since most code bases use the Latin alphabet for function names even when their native language uses a different alphabet, that means in most cases, there will be 26 sections, A through Z. (Some, like Q and X, are likely to be empty). But the implementation should be prepared to cope with any number of sections, and not just assume that there will be a maximum of 26 sections.
  4. All function names that do not start with a letter (e.g., operators) are grouped in their own section, separately from the names that do start with letters. So for a code base written with the Latin alphabet, that means there would likely be 27 sections at most. The non-letter section would be named something like !@#, though perhaps (operators) would also be a good section name.
  5. Each index section would produce its own HTML page, or there could also be an all-in-one HTML page that listed all functions. There could be advantages or disadvantages either way, and I'm not sure yet which would be best.
  6. At the top and bottom of each page, and in between each section in the all-in-one index page, would be a list of links that would take you to each section. E.g., A B C D E ... X Y Z (operators), where each letter is either a page-internal link (in the case of the all-in-one index page) or a link to the appropriate section page.
  7. Each function in the index has an indicator of which module it comes from, and whether its module has the AutoOpen attribute. This is particularly important in the case of the FAKE documentation, where it's currently very hard to tell which functions are immediately available by opening the Fake namespace. (At least, it's hard to tell that in the absence of good Intellisense from Ionide or similar IDEs. But FAKE scripts are the piece of F# code most likely to be edited without the benefit of an IDE, and FAKE is the project most desperately in need of an index).

As you can tell, this feature request is primarily driven by the needs of the FAKE documentation, but I think this will be a valuable feature for other projects' API docs as well.

@matthid
Copy link
Member

matthid commented Mar 30, 2017

On one side FAKE might need some cleanup very badly. In fact that's one thing I'm working on for Fake vnext (netcore).

On the other side I agree: A searchable index would be nice. Sometimes I wish there was something like this (when copying code from suave samples), because I'm a fan of not poluting my namespace (and only open some modules)

@dsyme
Copy link
Contributor

dsyme commented Jul 14, 2020

I believe we should do #529 instead (add a search index using Lunr)

@dsyme dsyme closed this as completed Jul 14, 2020
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

3 participants