Separate Inkuire docs

Author: KacperFKorban

scala3/scaladoc.md

@@ -67,72 +67,6 @@ This feature is provided by [Inkuire](https://github.com/VirtusLab/Inkuire) sear
 Note that this feature is still in development, so it can be subject to considerable change.
 If You encounter a bug or have an idea for improvement don't hesitate to create an issue on [Inkuire](https://github.com/VirtusLab/Inkuire/issues/new) or [dotty](https://github.com/lampepfl/dotty/issues/new).
 
-
-Using this feature allows to find `def`s and `val`s from the documented code.
-
-In order for a scaladoc searchbar query to be searched using Inkuire instead of the default search engine, the query has to contain `=>` character sequence. 
-
-Accepted input is similar to a curried function signature in Scala 3. With some differences:
-- AndTypes, OrTypes and Functions have to be enclosed in parentheses e.g. `(Int & Any) => String`
-- Transformations without any input can be found by a syntactic by name call e.g. `=> Int`
-- A wildcard `_` can be used to indicate that we want to match any type in a given place e.g. `Long => Double => _`
-- Types in the form of single letter e.g. `A` or a letter with a digit `X1` are automatically assumed to be type variables
-- Other type variables can be declared just like in polymorphic functions e.g. `[A, B] => A => B => A` 
-
-Some examples to give You a better idea:
-- `List[Int] => (Int => Long) => List[Long]`
-- `(A, B) => A`
-- `Set[Long] => Long => Boolean`
-- `Int => Long => Int`
-- `String => Int => Char`
-- `(Int & Float) => (String | Double)`
-
-Inkuire works as a JavaScript worker in the browser thanks to the power of [ScalaJS](https://www.scala-js.org/).
-
-To enable Inkuire when running scaladoc add flag `-Ygenerate-inkuire`. By adding this flag two files are generated:
-- `inkuire-db.json` - this is the file containing all searchable declarations from the currently documented project in a format readable to Inkuire search engine.
-- `inkuire-config.json` - this file contains locations of database files that should be searchable from documentation of the current project. By default it will be generated with the location of the local db file as well as default implied locations of detabase files in `External mappings`.
-
-When it comes to how the code is mapped to InkuireDb entries, there are some transformations to make the engine more opinionated(though open to suggestions and changes). Firstly the receiver(non-module owner) of a function can be treated as a first argument. Automatic currying is also applied, so that the results aren't dependant on argument lists. When finding matches `val`s and `def`s are not distinguished.
-
-So the following declarations should be found by query `Int => Int => Int => Int`:
-```
-class Num:
-  def a(i: Int, j: Int): Int
-  def b(i: Int)(j: Int): Int
-  def c(i: Int): (Int => Int)
-  val d: Int => Int => Int
-  val e: Int => Int => Int
-  val f: (Int, Int) => Int
-end Num
-
-def g(i: Num, j: Int, k: Int): Int
-extension (i: Num) def h(j: Int, k: Int): Int
-def i(i: Num, j: Int)(k: Int): Int
-extension (i: Num) def j(j: Int)(k: Int): Int
-...
-```
-
-When it comes to type aliases, they are desugared on both the declaration and the query signature. This means that for declarations:
-```
-type Name = String
-
-def fromName(name: Name): String
-def fromString(str: String): Name
-```
-both functions (`fromName` and `fromString`) should be found for queries `Name => Name`, `String => String`, `Name => String` and `String => Name`.
-
-The edges are the roughest with implicits/givens.
-Implicit conversions are only applied once and only to the receiver/first argument. Since allowing for more than one applicationof implicit conversions poses problems like for example infinite applications of implicit conversions.
-Implicit arguments are ignored at the moment, but we are very much planning on better support for them in near future.
-
-Some other things we are still working on:
-- Generating type information (InkuireDB) for Java sources
-- More advanced type level constructs like e.g. explicit type bounds and repeated types
-- Better managing of dependencies using scaladoc external mappings
-- Integration with [Metals](https://scalameta.org/metals/)
-- Optimizations
-
 [scaladoc-docstrings]: https://dotty.epfl.ch/docs/usage/scaladoc/scaladocDocstrings.html
 [static-documentation]: https://dotty.epfl.ch/docs/usage/scaladoc/staticSite.html
 [built-in-blog]: https://dotty.epfl.ch/docs/usage/scaladoc/blog.html

scala3/scaladoc/inkuire.md

@@ -0,0 +1,69 @@
+---
+layout: singlepage-overview
+title: Inkuire (Hoogle-like searches)
+---
+
+Using this feature allows to find `def`s and `val`s from the documented code.
+
+In order for a scaladoc searchbar query to be searched using Inkuire instead of the default search engine, the query has to contain `=>` character sequence. 
+
+Accepted input is similar to a curried function signature in Scala 3. With some differences:
+- AndTypes, OrTypes and Functions have to be enclosed in parentheses e.g. `(Int & Any) => String`
+- Transformations without any input can be found by a syntactic by name call e.g. `=> Int`
+- A wildcard `_` can be used to indicate that we want to match any type in a given place e.g. `Long => Double => _`
+- Types in the form of single letter e.g. `A` or a letter with a digit `X1` are automatically assumed to be type variables
+- Other type variables can be declared just like in polymorphic functions e.g. `[A, B] => A => B => A` 
+
+Some examples to give You a better idea:
+- `List[Int] => (Int => Long) => List[Long]`
+- `(A, B) => A`
+- `Set[Long] => Long => Boolean`
+- `Int => Long => Int`
+- `String => Int => Char`
+- `(Int & Float) => (String | Double)`
+
+Inkuire works as a JavaScript worker in the browser thanks to the power of [ScalaJS](https://www.scala-js.org/).
+
+To enable Inkuire when running scaladoc add flag `-Ygenerate-inkuire`. By adding this flag two files are generated:
+- `inkuire-db.json` - this is the file containing all searchable declarations from the currently documented project in a format readable to Inkuire search engine.
+- `inkuire-config.json` - this file contains locations of database files that should be searchable from documentation of the current project. By default it will be generated with the location of the local db file as well as default implied locations of detabase files in `External mappings`.
+
+When it comes to how the code is mapped to InkuireDb entries, there are some transformations to make the engine more opinionated(though open to suggestions and changes). Firstly the receiver(non-module owner) of a function can be treated as a first argument. Automatic currying is also applied, so that the results aren't dependant on argument lists. When finding matches `val`s and `def`s are not distinguished.
+
+So the following declarations should be found by query `Int => Int => Int => Int`:
+```
+class Num():
+  def a(i: Int, j: Int): Int
+  def b(i: Int)(j: Int): Int
+  def c(i: Int): (Int => Int)
+  val d: Int => Int => Int
+  val e: Int => Int => Int
+  val f: (Int, Int) => Int
+end Num
+
+def g(i: Num, j: Int, k: Int): Int
+extension (i: Num) def h(j: Int, k: Int): Int
+def i(i: Num, j: Int)(k: Int): Int
+extension (i: Num) def j(j: Int)(k: Int): Int
+...
+```
+
+When it comes to type aliases, they are desugared on both the declaration and the query signature. This means that for declarations:
+```
+type Name = String
+
+def fromName(name: Name): String
+def fromString(str: String): Name
+```
+both functions (`fromName` and `fromString`) should be found for queries `Name => Name`, `String => String`, `Name => String` and `String => Name`.
+
+The edges are the roughest with implicits/givens.
+Implicit conversions are only applied once and only to the receiver/first argument. Since allowing for more than one applicationof implicit conversions poses problems like for example infinite applications of implicit conversions.
+Implicit arguments are ignored at the moment, but we are very much planning on better support for them in near future.
+
+Some other things we are still working on:
+- Generating type information (InkuireDB) for Java sources
+- More advanced type level constructs like e.g. explicit type bounds and repeated types
+- Better managing of dependencies using scaladoc external mappings
+- Integration with [Metals](https://scalameta.org/metals/)
+- Optimizations