Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Language Server #1910

Merged
merged 6 commits into from Nov 6, 2019

Conversation

@philipcmonk
Copy link
Contributor

philipcmonk commented Nov 4, 2019

This PR pairs with the initial commit of hoon-language-server here and urbit/hoon.vim#18.

This adds a basic language server app. It communicates over HTTP with hoon-language-server, which communicates over stdio with any editor plugin that speaks the Language Server Protocol. Eventually we should make this app speak JSON RPC directly, so that if any proxy is needed it can be a dumb proxy (eg TCP to HTTP2). I've included configuration information in the hoon.vim readme for vim.

It has three basic features:

  • Autocomplete (using the same engine as #1899)
  • Syntax checking
  • Rune snippets

All three are displayed in this demo:

asciicast

Lots more should be done in terms of polish and new features, but this is minimally viable. I've disabled autocomplete and syntax checking for files larger than 1000 lines because it's slow, but if you don't care about rune snippets being available quickly, then you may as well enable it. Since they don't currently depend on any dynamic data, arguably rune snippets should be a static portable file, like TextMate snippets. We may add dynamic snippets later (eg if we parse how many arguments a function has).

I hacked together something for VS code which proves that it works, but I don't know that ecosystem well enough to make a real plugin for it. I followed this tutorial to modify this code to refer to hoon-languge-server instead of server.js, changed the transport to TransportKind.stdio, and I added runtime: "/usr/local/bin/python3 to the run and debug server options.

philipcmonk added 3 commits Nov 4, 2019
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
@galenwp

This comment has been minimized.

Copy link
Contributor

galenwp commented Nov 4, 2019

This is so, so cool

@belisarius222

This comment has been minimized.

Copy link
Contributor

belisarius222 commented Nov 4, 2019

I don't think I'll have time for a full review of this before my imminent vacation, which technically starts today. I have two comments so far:

  1. +runes in /rune-snippets/hoon will call +malt to reconstruct its constants every time, which is probably not that slow but really should be moved to run once at linking time.
  2. I can't wait to use this!
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
@philipcmonk philipcmonk force-pushed the philip/language-server branch from 1a46604 to 0713d3d Nov 5, 2019
Copy link
Member

joemfb left a comment

This is very cool. LGTM, barring a couple nits:

:: =; res
:: ?. ?=(%del -.dat)
:: res
:: (he-tab:res +(p.dat))

This comment has been minimized.

Copy link
@joemfb

joemfb Nov 6, 2019

Member

Is this just auto-tab on input? Any reason to include it?

This comment has been minimized.

Copy link
@philipcmonk

philipcmonk Nov 6, 2019

Author Contributor

yeah. it's exhilarating, but impractical; removed.

This comment has been minimized.

Copy link
@joemfb

joemfb Nov 6, 2019

Member

Something to remember, maybe it should be a configurable mode. For fun, if nothing else.

@@ -0,0 +1,29 @@
|%

This comment has been minimized.

Copy link
@joemfb

joemfb Nov 6, 2019

Member

This doesn't appear to be used. Is it relevant to this PR?

This comment has been minimized.

Copy link
@philipcmonk

philipcmonk Nov 6, 2019

Author Contributor

There were two times that I wanted a trie, so I wrote one. One use case was an attempt at partial caching of the parsing, but the gains were only about 20% so I nixed it. A trie would be the right data structure for filtering the identifiers in your subject according to the prefix you've typed, but I haven't used it because so far a list is fast enough.

As it's unused, I've removed it. If we need a trie in the future, we can pull it out of git history.

This comment has been minimized.

Copy link
@joemfb

joemfb Nov 6, 2019

Member

Makes sense. The entire autocomplete flow seems ripe for optimization and caching. But it's impressively fast already.

@joemfb
joemfb approved these changes Nov 6, 2019
Copy link
Member

joemfb left a comment

LGTM

jtobin added a commit that referenced this pull request Nov 6, 2019
* philip/language-server:
  language-server: address review comments
  language-server: fix rune typos
  language-server: multiple files and ford
  language-server: namespace libraries
  language-server: cleanup and incremental text sync
  language-server: initial commit

Signed-off-by: Jared Tobin <jared@tlon.io>
@jtobin jtobin merged commit 545fe25 into master Nov 6, 2019
1 check passed
1 check passed
continuous-integration/travis-ci/push The Travis CI build passed
Details
@jtobin jtobin deleted the philip/language-server branch Nov 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.