+find-item-in-type and everything it called was pretty bad spaghetti and
it wasn't clear that it was doing this right thing besides that it
passed tests. this refactors most of that functionality into a door that
has the type and search terms as the sample, and should be much easier
to follow.
the remaining functionality related to arm docs ought to be refactored
as well
this makes it so that when an arm matches a search query in
+find-item-in-type, it checks to see if the arm builds a core with an
arm other than %$. if so, a %core item is returned rather than an %arm
item.
the name of the core will then be considered to be the name of the arm
that builds it
since cores can't be given names in v0 doccords, this changes the main
search function in lib/dprint to check if the summary of a core
description matches the search term, along with other appropriate
changes downstream of this.
still to be done: use .name in a %core item for either this summary name
or the name of the arm that built the core, if appropriate
this is to handle potential future cases where doccords might be kinds
of notes other than %help notes. example: #6085 to document invariants
in clay.
$whit (used for apex:docs/batch comments) also ought to be changed but
im still thinking about what that should look like.
partial revert of 3d3ea61d53, which introduced core names by completing
an unimplemented feature that was already present in hoon.hoon. we've
decided to remove this for the initial launch since it violates the
principle of least surprise for the name of a core to end up in its
$garb and yet only be used for doccords, as opposed to something like a
wing resolution. it was also confusing that this only worked for |% and
|@.
this breaks two of the tests for the dprint library, which have been
commented out. these tests ought to be restored once dprint is rewritten
in order to implement a different way to refer to cores not built by arms
this constitutes a pretty major rework of how whitespace is handled in
hoon in order to change the doccords syntax from :> and :< to ::.
in summary: throughout the hoon parser (+vast) many instances of +gap
have been replaced by +jump, which first tries to remove whitespace (+leap)
until it arrives at something that can be parsed as a prefix
doccord (+apex:docs:vast). if it does not encounter a doccord, it
instead uses +gap as normal.
if you follow along with the parser, you will notice that every time
jump is called, it then tries to call +apex:docs via +scye or +seam. if
apex:docs succeeds, it will end up consuming a newline at the end,
hiding the fact that there was valid whitespace from the parser. thus
+apex:docs then inserts a newline after successfully parsing a prefix
doccord, which will then be consumed by a subsequent invocation of +gap,
ensuring that there was proper whitespace if the doccord would have been
consumed by +gap instead of +leap.
there are a few other changes:
+hint in the compiler throws out doccords attached to %noun types. this
was already the behavior before doccords, and the change was made before
i understood what i was doing.
similarly for commenting out the %note case in +open:ap - this was an
earlier mistake
postfix comments for chapters are now enabled.
+expx was unused and removed in order to be rid of the
convention-defying +exp1. other unused +ex(p/q)* were commented out.
arms that handle batch comments (+glow and +whap) were refactored
+toad, which was used to change between tall and wide form, tries to
+jump before +gap. since +jump is ;~(pose leap:docs gap), i would have
thought that just using +jump there would be fine, but it fails for some
reason.
some parsers built with |@ were rewritten to use |*
|$ was made so that any doccords put on the spec are converted into hoon
doccords on the $ arm. it wouldn't compile otherwise. there's probably a
more principled way to do this but it works fine for now.
The +on-cork handler asserts that the peer is known to us. This is the
incorrect behaviour, because it will crash when corking a flow to a peer
that is still an %alien. This can happen, for instance, when making a
gall subscription for the first time and then corking it before the
alien naturalises.
PR #5840 mostly fixed#1559, but introduced a new bug. before, you could safely `=dir` into a desk without a case, and it would use the nonexistent case `ud+0` as the beam for dojo state, and switch that out for da+now whenever it tries to resolve the current path. but this check causes it to fail, because `ud+0` is a nonexistent case. this uses he-beam to transform the beam in the conditional to see if the case is 0, and if it is, changes the case to da+now before it scries
Eyre always gets passed request headers in lowercase, so we should search for
the lowercased version of the header.
Arguably `+get-header` should lowercase keys before comparing them, but that's
a more serious behavioral change.
