Open tpapastylianou opened 2 years ago
I think packages (mostly?) provide an INDEX file (e.g., https://github.com/cbm755/octsympy/blob/main/INDEX).
So it "just" needs someone to do the work... Note magical word "just".
Note that this is only true for 'traditional' packages. Since one of the stated goals of this page is to enable developers to also list 'non-traditional' packages, there needs to be a mechanism to include them too in such a search, if possible.
Of course, this could be as simple as requesting that developers provide a compatible INDEX file, which could then be searched for by the search engine when in 'function lookup' mode instead of 'package lookup'.
Which also then raises the question of what kind of interface should one go for when searching functions instead of packages. A toggle in the main page? Or a completely separate index listing all indexed functions by package?
A function lookup capability through an INDEX file or any other mechanism would be also very useful to detect shadowing of functions among different packages. This would help both package maintainers/developers and users alike.
IMHO it would be much easier to implement if package maintainers would provide a typical INDEX file independently of traditional or non-traditional package design.
pkg-octave-doc
package provides the functionality to generate a full list of functions available within a package (without generating the corresponding HTML pages). Perhaps, it could be useful for aggregating all functions' names from every package available in Octave Packages, but it is still bounded to those packages that can be installed with the pkg
command.
I could implement a workflow for automatically finding all packages that can be installed this way (with pkg
) and produce some custom HTML for indexing all functions alphabetically with the package(s) they belong to.
On an additional matter, it would be very helpful if we would transfer our package repositories to GitHub, so we can make full use of the pkg-octave-doc
package and start building HTML documentation with the use of GitHub pages, since Octave Forge is no more actively maintained.
Feature request is to add the ability to search for individual function names within packages. This would enhance the functionality of the search feature, allowing users to quickly find specific functions within packages instead of searching through the entire package documentation.
i want to work on this issues please assign me this issue.
You are welcome to work on it and make a PR, once you have a working prototype
i don't no how it can be remove so ,Please assignees problem again.
I am afraid I don't understand what you mean. Can you elaborate?
@pr0m1th3as Hey is this problem under someone or can I work on it? Would u please assign me?
@pr0m1th3as Hey is this problem under someone or can I work on it? Would u please assign me?
It was previously assigned to @vivekd01, but we haven't received any patch or heard from him ever since. To be honest, I am not sure how this functionality would/could be integrated into the packages
repository and auto-generated GitHub pages in a way that does not disrupt the current package listing. I suggest that it would require
However, it could always be done in a separate repository. So far, I have implemented some extra functionality into the pkg-octave-doc
package that can facilitate retrieving all available packages and their urls. You could go ahead and build on that a new function that can parse the INDEX files from each individual package to assemble a comprehensive list of available functions and classes. You can get further ideas from another function I posted in a discourse thread here.
I know this is a non-trivial request, and may or may not already be part of the goal for this project, but I thought I'd open this as an issue to have a proper place for it.
Essentially, if this page is going to partly replace what octave-forge was used for (in terms of acting as a repository of packages), it would be useful to be able to search "inside" packages, for the presence (and possibly documentation) of provided functions.
One way this could be achieved is if package maintainers were asked to provide a list of provided functions (preferably with a link to documentation) with their packages, that could then be searched from the main search interface.