Action/Server reorder modules #393
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
cc @smatting |
Profpatsch
changed the title
|
I noticed a problem with this; the documentation & module was previously taken just from the first module in each target list, but after filtering out everything that does not contain a (module or package) in the target, some results might be left without any results, meaning the partial match on |
|
The problem should be fixed now & the PR ready for review. |
The `local` and `haddock` booleans are only used for determining the URLs to generate, so let’s make that clear.
The function does not really deduplicate the elements, it takes and groups. :)
Upstream does not think shadowing should be avoided, so let’s undo the changes to shadowing. Same with incomplete pattern warnings, we’ll just let it crash for now. Also drop the `Is*` prefix for the URL constructors.
CI unfortunately uses -Werror and tests against more modern versions of GHC, so any new errors will only appear on CI.
The way the template was filled was rather hard to follow. This tries to remedy it by splitting the code which infers the data from the list of targets, and the code which generates the HTML. The logic should be exactly the same, but we use a sort->groupBy to stable-sort Targets into their packages.
This will *not* change the top-link for the target to the first module, just switch around the displayed list. We need to push the logic out a bit further to change the top target.
Previously only the module list was reversed, but the main link to a search result would still point to the first module in the non-reversed list. This uses the logic for both the `showFroms` and the main result loop. Note that the order of *packages* is still pretty much arbitrary, so the user might still land in a package other than where the symbol was originally defined. But for example in the case of `find`, the `base` package is most often displayed first, and the `find` from `Data.Foldable` will now take precedence of the reexport from the reexport in `Data.List`.
After reversing the module list, we have a pretty good topological order for modules, meaning the main link of a search result target (and the first module displayed) will usually be the definition of that target. There is however a convention to expose `.Internal` modules so that users can use unstable APIs if they have a need to. So in case the first module is such an `.Internal` module, we want to sort it back and display the next module in the list first. For example the result ``` toList :: IntSet -> [Key] containers Data.IntSet.Internal Data.IntSet ``` will now be displayed as ``` toList :: IntSet -> [Key] containers Data.IntSet Data.IntSet.Internal ``` and link to `Data.IntSet` by default.
Sometimes all targets in the target lists are filtered out by the mapMaybe in `showFromsLogic`, in that case we just fall back to the head of the original result.
Profpatsch
force-pushed
the
action-server-reorder-modules
branch
from
7ee31dd to
4866a5b
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
(This is on top of #392)
The previous sorting of modules within packages meant that the first link would usually point to some random re-export of the definition. I figured out that the modules where in reversed topological order, so by reversing & applying a heuristic for internal modules, we get vastly improved default module links.
Action/Server: reverse the order of modules in showFroms
This will not change the top-link for the target to the first
module, just switch around the displayed list.
We need to push the logic out a bit further to change the top target.
Action/Server: Take the main search result link from reversed module
Previously only the module list was reversed, but the main link to a
search result would still point to the first module in the
non-reversed list.
This uses the logic for both the
showFromsand the main result loop.Note that the order of packages is still pretty much arbitrary, so
the user might still land in a package other than where the symbol was
originally defined.
But for example in the case of
find, thebasepackage is mostoften displayed first, and the
findfromData.Foldablewill nowtake precedence of the reexport from the reexport in
Data.List.Action/Server: Sort any leading Internal module to the back
After reversing the module list, we have a pretty good topological
order for modules, meaning the main link of a search result
target (and the first module displayed) will usually be the definition
of that target.
There is however a convention to expose
.Internalmodules so thatusers can use unstable APIs if they have a need to.
So in case the first module is such an
.Internalmodule, we want tosort it back and display the next module in the list first.
For example the result
will now be displayed as
and link to
Data.IntSetby default.