Open nicklawls opened 4 years ago
You might want to ask these questions in one of the unison slack channels https://www.unisonweb.org/community
Excellent suggestion @francisdb!
Made a separate issue to start tracking Doc
s rendering, which seems like some good low-hanging fruit
https://github.com/unisonweb/elm-browser/issues/65
Although handling builtin.Doc.Evaluate
will be tricky!
Notes from discussion:
Going to focus on just having a viewer of individual definitions, which has very few unknowns and is also incredibly useful.
Some bikeshedding on URL format that we were just whiteboarding:
www.unisonweb.org/browse/(github|gitlab)/xilnocas/myunisoncode/latest/by-name/path/to/mydefinition
www.unisonweb.org/browse/(github|gitlab)/xilnocas/myunisoncode/<namespacehash>/by-name/path/to/mydefinition
www.unisonweb.org/browse/(github|gitlab)/xilnocas/myunisoncode/<namespacehash>/by-name/path/to/mydefinition
www.unisonweb.org/browse/(github|gitlab)/xilnocas/myunisoncode/<namespacehash>/by-hash/<hash>
Doc Evaluate
nodes can just be rendered as links to the source of the definition being evaluated with some subtle indicator + tooltip about how the user can evaluate the definition locally.
Idea: Maybe the view page for a definition gives the UCM instructions for fetching that definition at the bottom. ("How do I get this definition?")
We should use a URL format that supports git branches and git hashes and supports looking up definitions named /
.
I recommend checking UriParser.hs
for inspiration!
Something like this should also work: https://github.com/unisonweb/unison/blob/c8e7f002a2d8858cdd961bbaa300ebc55318ee95/parser-typechecker/src/Unison/Codebase/Editor/UriParser.hs#L26-L55
I took a first crack at URLs based on @pchiusano's comment from last week.... didn't notice @aryairani's additions till afterward 😅
I can report that elm/url
's parser API wouldn't let me parse arbitrary length paths (.../path/to/mydefinition
), so I needed to resort to .path.to.mydefinition
anyway. That pushes things pretty darn close to the format outlined in the link above, so maybe we should just go the rest of the way there for ecosystem consistency.
It supports branch names, which are hard to parse without IO that literally checks for the existence of such a branch, because they can include .
, /
; everything but :
, basically. :-\
And... I couldn't bring myself to not support git branches, given what a fundamental part of git they are.
Reading this in the last Unison blog post got me all jazzed up:
That said, having peeked back into the code here for the past few days, I'm unclear as to how far towards that goal everything is. I wanna ask some general questions here, and hopefully generate enough discussion to write up issues that will get this baby shippable.
Do we know what the URL format will be?
www.unisonweb.org/browse/<git-stuff>/<hash>
? Lots of optionsHow will the server handle all the git data it'll be dealing with from across the internet? Just pull the files over the network a-la-carte? Clone a whole repo the first time it sees it? (Edit: it looks like there's actually some preliminary elm code for getting files from GitHub. I suppose we could do it client side as well)
How much tweaking does the UI need? The current trajectory seems to be towards something very much like the elm-package site, with the currently focused namespace in the main content area, and a filterable list of sibling namespaces off to the right (example). But of course for each type and term definition we should display hyperlinked source code, in addition to any linked docs and tests
Are "Branch"es a user facing thing? It seems to me that maybe "namespaces" or "paths" are the user-facing abstractions that are implemented by branches under the covers.
Perhaps related to the above, do we really want the little predecessors/parents/successors control at the top of the page? It seems to be going through history somehow, but it's doing it in a way that changes what gets rendered in the right sidebar. Not sure how to interpret all that.
How much provenance of definitions should we show? Say my library depends on some well known/trusted library called 'foobar', which I, following its readme instructions, installed via
pull https://github.com/foobar-author/foobar .foobar
in theucm
shell. Wouldn't it be nice for users of my code to see that everything from.foobar
is the same set of well-known code they're used to seeing? The names alone aren't enough to tell you that.