Allows language-server to commit automatically upon changes. This
is driven by the editor, preventing the autocommit issues seen
with #971. Additionally recalculates syntax issues upon save.
* origin/invite-app:
chat-hook: upgrade from old state and perform invitatory creation and subscription
invite-hook: crash upon invalid invite received
changed invite peek interface to /:path/:uid
invite: add comments and clean up
chat-js: added invite functionality
chat-hook: added invite functionality
app: added invite app and mark converters to JSON
Signed-off-by: Jared Tobin <jared@tlon.io>
* eth-watcher-2: (21 commits)
eth: move existing chain requests into ethio
eth-watcher: refactor refresh rate to top of file
hook: add pool-group-hook for making invite groups
ethio: add +read-contract for chain state reading
zuse: add delegated-sending address
eth: move eth-watcher's request-rpc into ethio lib
gaze: make compile for latest eth-watcher
drum: start eth-watcher on boot
azimuth-tracker: remove deprecated generator
eth: implement azimuth-tracker using eth-watcher
eth-watcher: ensure logs always sent oldest-first
eth-watcher: allow peers to unconfigured watchdogs
eth-watcher: saner %watch behavior
eth-watcher: implement %clear poke
eth-watcher: store logs in state to implement peer
eth-watcher: move types into /sur file
eth-watcher: properly tag out-peer-data
eth-watcher: single update timer loop
eth-watcher: implement /block peek
eth: turn azimuth-tracker into eth-watcher
...
Signed-off-by: Jared Tobin <jared@tlon.io>
Handle multiple files by keeping a map of text buffers. Also use the
Ford parser so we can parse ford runes. At some point we should load in
libraries when that happens so we have the appropriate types.
This corresponds to hoon-language-server 0.1.1
A simple language server engine, for use with hoonls.py, which presents
the RPC interface expected by editors. Features:
- Syntax error detection
- Rune snippets
- Autocomplete
* philip/tab-complete:
auto: gain and lose types on ?:
auto: handle tab in middle of symbol
auto: support forks
auto: support autocomplete inside wings
auto: fix some crashes on strange wet gates
auto: support multiline tab completion
auto: don't look in context of non-gold cores
easy-print: don't crash if type-check crashes
dojo, drum: change %tab sole-effect to use tanks
dojo, auto: move insert-magic logic to lib/auto
dojo, drum: give tab completion as true output
dojo: add a better function printer
dojo: add tab completion
Signed-off-by: Jared Tobin <jared@tlon.io>
The link used here resolves with a 301 to the proper page for messaging usage, but not actually the 'messaging' section of that page. This commit provides a more direct link to the exact instructions.
This changes the entry-points in lib/auto so that clients never have to
handle magic-spoon. You can specify either a tape of code with a
position index or a preparsed hoon (presumably you ran +insert-magic
before parsing).
This stops slogging the tab completion and intead adds a +sole-effect
for tab completion output. This is morally correct, and it lets dojo
clients show tab completions how they want. For example, web dojo could
implement this as a drop-down box.
Another advantage is that this puts the rendering logic in drum, which
knows the width of the terminal. Thus, we can make sure each match
takes no more than one line by truncating with ellipses. If there's
only one match and it's already fully typed, then we display the whole
type.
It's useful to know what a function takes and produces, so this changes the autocomplete type prettyprinter to emphasize those. This also gives a nice syntax for molds. Examples:
```
-----
add {a/@ b/@} -> @
~zod:dojo> add
-----
term * -> @tas
~zod:dojo> term
-----
sign-transaction {tx/{nonce/@ud gas-price/@ud gas/@ud to/@ux value/@ud data/@ux chain-id/@ux} pk/@} -> @ux
~zod:dojo> sign-transaction🔑ethereum
-----
wind {a/(* -> *) b/(* -> *)} -> * -> ?({$give p/*} {$pass p// q/*} {$slip p/*})
~zod:dojo> wind
```
This is initial support for type-aware tab completion. When you hit tab, it tries to complete the word you're in the middle of using a face or arm in the subject at that point in the code. It also shows all possible matches and their associated types. It's nearly instantaneous. Notes:
- It advances to the longest common prefix, so if you hit tab on `ab` and the only possible results are `abcde` and `abcdz`, then it'll write `abcd` and print both out (with their types).
- If there are fewer than ten matches, it prints the type along with the face. Printing types is too slow to use all the time, but with 10 it's essentially instantaneous.
- The match closest in the subject to you (i.e. smallest axis number) is displayed lowest (closest to your focus).
Examples below, where `<TAB>` represents me hitting tab while my cursor is at that position (the line with the `<TAB>` is not preserved in the actual output).
```
~zod:dojo> eth<TAB>
-----
ethereum #t/<11.qcl {<3.ltb 27.ipf 7.ecf 36.uek 92.bjk 247.ows 51.mvt 126.xjf 41.mac 1.ane $141> <21.yeb 27.ipf 7.ecf 36.uek 92.bjk 247.ows 51.mvt 126.xjf 41.mac 1.ane $141>}>
ethereum-types #t/<3.ltb 27.ipf 7.ecf 36.uek 92.bjk 247.ows 51.mvt 126.xjf 41.mac 1.ane $141>
~zod:dojo> ethereum
~zod:dojo> |= zong=@ud z<TAB>
-----
zing #t/<1.dqs {* <126.xjf 41.mac 1.ane $141>}>
zap #t/<1.iot {tub/{p/{p/@ud q/@ud} q/""} <1.rff {daf/@t <247.ows 51.mvt 126.xjf 41.mac 1.ane $141>}>}>
zuse #t/$309
zong #t/@ud
~zod:dojo> |= zong=@ud zo<TAB>
-----
zong #t/@ud
~zod:dojo> |= zong=@ud zong
~zod:dojo> <TAB>
hoon-version
trel
quip
pole
unit
qual
lone
... about 600 more lines ...
unity
html
zuse
eny
now
our
~zod:dojo>
```
Functionally, this is in a state where I'd be comfortable shipping it. It doesn't interfere with anything if you don't press tab, and it's perfectly OTA-able. I do think its output is a little verbose, but that can be tuned over time as people try it and determine what feels good in practice.
Additional notes:
- There are plenty of similar systems for other languages, but my most direct inspiration is Idris's editor tools. This is implemented for the dojo, but I actually want it in my editor, which is why the meat is all defind in a library. I've only tested on dojo one-liners, so I don't know the performance on large blocks of code.
- The default type printer isn't great for this use case. In particular,
- Cores should not print anything about their context
- The `#t/` should go away
- If it looks like a gate, we should print its return value
- Maybe special handling for molds, but if the above is done, then for example `bone` is `* -> @ud`.
- The worst part about our wing ordering is that it really screws up tab completion. You want to do `point.owner-address` instead of `owner-address.point` because that lets you type `point.ow<TAB>`. I weakly prefer reading it how we do it now, but it's really not great. You could do an (dojo-specific?) alternate syntax of `point;owner-address`; this is a simple transformation.
- Regardless of the above, this should handle the case where we're in the middle of defining a wing; it doesn't right now.
- When a variable is shadowed, we show both of them. We should probably show the shadowed one with a `^`.
- We probably shouldn't print out hundreds of results. Maybe just the closest 50 with ellipses.
- This gets you any face in your subject, regardless of whether its type is reasonable. We could limit that some by copying the `gol` logic in mint, so that if the pseudo-backward-inference engine happens to know what type it should be, you can filter the tab results according to if they nest in that type. This would be "strongly type-aware".
Re-implements the behavior of the previous azimuth-tracker as an app
that pokes and peers eth-watcher. Should have maintained identical
outward semantics to the original.
When configuring a watchdog on a path that already exists, we now
"overwrite" it, meaning we throw away all history and trawl the node
for logs again.
If the only config change is the url, however, we silently modify it,
and simply use it "from this point onward".
This matches the behavior of the original azimuth-tracker.
In order to give an initial response to incoming subscriptions (without
resorting to retrieving that data from chain again) we now store event
log history in state.
Instead of discarding pending-logs entirely after sending out updates,
we add them to the watchdog's history.
Just like pending-logs, we remove from the head during a rewind (though
not before exhausting the pending-logs).
