Right now Atom does not record or send the position of where the context menu was created and so the LSP relies on the cursor position when Go To Declaration is activated from that menu (and potentially Rename Symbol in the future)

Atom should additionally send the nearest line and character position with the message so that it can be utilized in such calls.

I get a JSON parse error "Uncaught SyntaxError: Unexpected end of JSON input" at /home/e/.atom/packages/language-e/node_modules/atom-languageclient/node_modules/vscode-jsonrpc/lib/messageReader.js:202. Full backtrace:

at StreamMessageReader.onData (/home/e/.atom/packages/language-e/node_modules/atom-languageclient/node_modules/vscode-jsonrpc/lib/messageReader.js:202:23)
    at Socket.<anonymous> (/home/e/.atom/packages/language-e/node_modules/atom-languageclient/node_modules/vscode-jsonrpc/lib/messageReader.js:166:19)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:188:7)
    at readableAddChunk (_stream_readable.js:176:18)
    at Socket.Readable.push (_stream_readable.js:134:10)
    at Pipe.onread (net.js:543:20)

I modified that line of code where the error occurs to output the JSON that fails to parse there, and I get this output (yes, it's cut off at the end):

{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"processId":13592,"capabilities":{},"rootPath":"/home/e/Develop/e-language-serve

I tested this with a binary that just eats stdin and never outputs anything ever as a language server. Obviously, as a result this message cannot be generated by anything except atom-languageclient itself. Therefore, I think this might be a bug?

Edit: dunno if relevant, but I was using this incredibly simple plugin code that is almost unmodified from the README.md to run atom-languageclient when hitting this issue: https://gitlab.com/e/atom-language-plugin/blob/53c84ff2554807b3d3749c3331e867accb5664c5/lib/main.js

Nuclide/atom-ide-ui's outline view queries for a document's outline as soon as it's opened. Since atom-languageclient often initializes when the first file is opened, this means that the outline view request can often come before the server's ready.

In the outline view provider (https://github.com/atom/atom-languageclient/blob/master/lib/auto-languageclient.js#L232) the request is skipped if the server isn't active yet. Is it possible to change this to include starting servers as well? I think that'd be sufficient; the outline view provider could wait for the server to start before sending the symbols request.

The LSP protocol requires you initialize with a root path or url it can start examining.

What do we do about Atom projects/workspaces with multiple project folders?

Options

1. Nothing - a lot of stuff would appear to be broken
2. Fire up an LSP for each folder
   ...

The textDocument/rename protocol lets you rename a symbol and automatically update all associated symbols.

We could implement this with a command and a right-menu button but it would also need a ui for the new symbol unless we could do it inline.

We need to be able to tell LSP servers when we notice a file has changed on disk.

Challenges

• Atom does not expose it's current change-notification system
• The change-watching npm libraries available all have issues on one platform or another

AutomComplete+ suggestion has descriptionMarkdown property that can accept MarkDown format documentation for completion proposals.

Here is the PR: #69

Hi, I have created an atom consumer package for this Golang server ( https://github.com/sourcegraph/go-langserver/ )

Literally everything works as well as it does in VSCode (which is amazing). Only one thing that does not is the hover/datatip thing. If I have following code:

`package main
import fmt

func main() {
fmt.Println("Hello")
someNumber := 3
fmt.Println(someNumber)
}`

and hover over "Println" (or "someNumber") nothing happens. If I move the cursor over Println and then execute "Nuclide: Datatip toggle" nothing happens. The DevTool (console) doesn't output anything either which is really strange seeing all other features work perfectly fine. Any idea as to what has gone wrong? It cannot be the fault of my consumer since all features (besides the hover) work. It cannot be the fault of the lang-server since it works on the same file under vscode. At least that's my thought process

The implementation of the consumer is 99% copy pasted from the Java package.

Hi, with my first test binary as a language server I am often only getting a request header (with Content-Length specified and the following \n\n line breaks) and no contents on stdin. It seems almost like it is line break or even block buffered and atom-languageclient doesn't flush the stdin pipe after a request so it's stuck somewhere in between in buffer limbo.

I tried everything I know to get rid of the buffering on my side (I'm using Python 3) but it's hard to test since in a terminal it behaves differently due to the way the libc operates. However, I believe a flush on the sending side (atom-languageclient) could easily fix this too.

Is there any chance you could add more aggressive pipe flushing after requests to prevent stuff getting stuck in buffering when sent through atom-languageclient --stdin--> language-server?

I'm working on a language client package for scry and I need to be able to start the server binary with the cwd as the projectPath. There doesn't appear to be an easy and preferred way to get then when starting the server at the moment. Some guidance would be super appreciated.

Relevant part of spec:

interface ServerCapabilities {
	/**
	 * Defines how text documents are synced. Is either a detailed structure defining each notification or
	 * for backwards compatibility the TextDocumentSyncKind number.
	 */
	textDocumentSync?: TextDocumentSyncOptions | number;

compare with the following in https://github.com/atom/atom-languageclient/blob/master/lib/languageclient.js#L416

export type ServerCapabilities = {
  // Defines how text documents are synced.
  textDocumentSync?: number,

I am trying to develop a plugin to integrate RLS with Atom using this library. My plugin code is here: https://github.com/aergonaut/languageserver-rust

I set up the plugin following the languageserver-java plugin as an example, along with some inspiration from the vscode-rust extension for VSCode, which also uses RLS. Autocomplete works, and so does the Nuclide definitions view and the Hyperclick go-to definition.

The problem I'm having now is that lint diagnostics aren't showing up with Linter.

I have Linter installed and I also made sure to disable the linter-rust plugin. I enabled the "core.debugLSP" setting in my config file so I could get more logging from atom-languageclient about what was going on.

I see the textDocument/publishDiagnostics message get received in the console log and the payload looks like it contains the right information to indicate where the error is.

However, I don't see any of Linter's tooltips popping up in the editor and I don't see any problems reported in Linter's panel.

Is there something simple I'm missing in my package? I'm not sure how to debug further since there's no logging in the code that processes the diagnostics and creates Linter messages.

I wish to make an integration of atom-languageclient with Rust Language Server (https://github.com/rust-lang-nursery/rls). Is this repository supporting it currently? How to proceed using this? Any documentation?

Sometimes the language server doesn't start when it should - this is because Atom can create multiple grammar objects for the same grammar.

We need to be able to match based on the names rather than object equality.

The textDocument/hover api allows additional information about a section of the document to be displayed in a hover/tool-tip style fashion.

Challenges

• Nuclide has datatips for this but expect a react component not markdown as returned by LSP

Currently, the definition/hyperclick providers query textDocument/documentHighlight to figure out what to highlight.

However, in both Nuclide and VSCode (https://github.com/Microsoft/vscode/blob/ff9f7b3baa6052863b55e8b6ef7c7c94d07beddf/src/vs/editor/contrib/goToDeclaration/browser/goToDeclaration.ts#L437), we simply highlight the word under the cursor (in Atom, we use the word regex as defined in the text editor).

This has the benefit of working for providers which don't implement word highlighting.
Also, it looks a bit weird to highlight all the references in the document.

@damieng would you be OK with this change/simplification?

If createServerProcess() returns a deferred promise that takes a longer time, atom-languageclient will emit errors when the user dares typing too early. This seems to happen because the serverCapabilities info from the initialized method aren't set yet, and if you type and the completion mechanism is invoked, there doesn't seem to be a proper check to whether the server process was actually created yet:

Uncaught TypeError: Cannot read property 'completionProvider' of undefined
/home/jonas/.atom/packages/language-tethercode/node_modules/atom-languageclient/build/lib/auto-languageclient.js:166
Hide Stack Trace
TypeError: Cannot read property 'completionProvider' of undefined
    at TethercodeLanguageServer.getSuggestions (/home/jonas/.atom/packages/language-tethercode/node_modules/atom-languageclient/build/lib/auto-languageclient.js:166:34)
    at /usr/share/atom/resources/app.asar/node_modules/autocomplete-plus/lib/autocomplete-manager.js:325:56
    at Array.forEach (native)
    at AutocompleteManager.module.exports.AutocompleteManager.getSuggestionsFromProviders (/usr/share/atom/resources/app.asar/node_modules/autocomplete-plus/lib/autocomplete-manager.js:304:17)
    at AutocompleteManager.getSuggestionsFromProviders (/usr/share/atom/resources/app.asar/node_modules/autocomplete-plus/lib/autocomplete-manager.js:3:61)
    at AutocompleteManager.module.exports.AutocompleteManager.findSuggestions (/usr/share/atom/resources/app.asar/node_modules/autocomplete-plus/lib/autocomplete-manager.js:291:19)
    at /usr/share/atom/resources/app.asar/node_modules/autocomplete-plus/lib/autocomplete-manager.js:3:61

To reproduce, make a minimal test plugin which returns a promise as seen here: https://github.com/atom/languageserver-php/blob/master/lib/main.js#L19 .. but which wraps the resolve() call in a setTimeout with a long duration (e.g. 15 seconds).

Then with the plugin active, type a dot or something that will trigger auto completion. If you do that before the resolve() was actually triggered yet, you should see an error.

Edit: to address the obvious question "why would you do that anyway"? While not needed for stdin-based language servers, TCP-based ones have an inherent waiting time (when the server is written as an actual TCP server waiting for incoming connections) because after launching the process you cannot immediately dump into the stdin pipe and wait for it to get parsed, but you need to wait until the process actually opened up the listening socket which can take a few milliseconds or longer. Also, just to find a free port I need to use node.js networking which is asynchronous by design, so that alone makes it almost impossible to instantly guarantee a working language server connection when the createServerProcess() function returns. Therefore, I suggest this use case should be fixed and atom-languageclient should expect and deal properly with some asynchronous delay until the server connection is actually ready.

I reworked it to work with TextEdits. I think this should be sufficient for the LSP range formatting API (the textedit type doesn't match exactly but it's really close.)

API: https://github.com/facebook/nuclide/blob/master/pkg/nuclide-code-format/lib/types.js#L24
Nuclide TextEdit: https://github.com/facebook/nuclide/blob/master/pkg/nuclide-textedit/lib/rpc-types.js

I'll probably send in a PR for this when I get the time.

The LSP protocol supports a telemetry/event message.

We currently ignore all of these but should decide what we want to do here if anything.

An LSP server can emit log messages using window/logMessage

We also like to emit various diagnostic information from the atom-languageclient library.

It would be great if Atom had a bundled logging UI that Atom and packages could write to that allowed categorisation/sorting/searching copy messages.

Need to determine if and how this could integrate into Atom.

I think this can make an option since autocomplete in atom cannot complete parameters in the fly like vscode.

The language client gets activated when working with files whose language matches getGrammarScopes. But once activated, document synchronization actions are triggered for all files, because the editor selector function passed to DocumentSyncAdapter disregards getGrammarScopes.

An LSP server can reveal additional information about a function via the textDocument/signatureHelp call.

We should write a text or block decoration that exposes these as appropriate.

Some linters return possibilities for fixing the code.

We should either expose these through Nuclide diagnostics fixers (recommended) or look at a UI affordance to expose it (that could be-used for Code Actions #11)

We need to be able do discover IDE packages and the scopes they support dynamically in order to offer suggestions in the future.

Move the grammarScopes from the main.js into package.json. This should be communicated to other package authors.

Currently the autocompletion results do not get filtered or sorted. This behavior is confusing and breaks the tab completion, because the first item is used, not the best matching one.

That's what it currently looks like or me:

That's what I would expect:

I created a PR to implement filtering using atom/fuzzaldrin.

Which basically does this:

autocomplete-adapter.js

static completionItemsToSuggestions(completionItems: Array<CompletionItem> | CompletionList, request: atom$AutocompleteRequest): Array<atom$AutocompleteSuggestion> {
  return filter(
    (Array.isArray(completionItems) ? completionItems : completionItems.items || [])
      .map(s => AutocompleteAdapter.completionItemToSuggestion(s, request)),
    request.prefix,
    {key: 'filterText'}
  );
}

Please let me know what you think.

Currently, typing a character will issue the autocomplete request before the document/didChange message goes through. This is because we're using onDidStopChanging to transmit buffer changes, so there's a ~300ms debounce (while autocomplete requests have a 100ms debounce).

I think @wbinnssmith mentioned this already, but should we just go back to using onDidChange?

Currently the diagnostic source is exposed as description in the Indie Linter API, which Nuclide renders by appending (but I think the Indie linter shows this when you hover over the error). It doesn't look great in the diagnostics table.

We should probably figure out a better way to do this. The Indie message API has a (not-for-public-use) linterName field: https://github.com/steelbrain/linter/blob/master/docs/types/linter-message-v2.md

Should we lobby to make that part of the public API? I think the implementation would be pretty trivial - the linterName would default to the registered name, but if you provide linterName in your message it'll override that.

The necessary UI components to support atom-languageclient are being developed over in https://github.com/facebook/nuclide/tree/master/modules/atom-ide-ui (or rather, they're being moved in from Nuclide piece-by-piece), which will soon be published as a standalone package.

This checklist tracks the progress of that effort.

Beta launch blockers

• Make the Nuclide unified package loader reusable for atom-ide-ui (@wbinnssmith)
• Move all packages into atom-ide-ui
  • hyperclick
  • diagnostics / diagnostics-ui
  • busy-signal
  • code-format
  • code-highlight
  • datatip
  • definitions
  • definition-service (just dropping this)
    • Drop unused getDefinitionById API
  • find-references
  • outline-view
  • hyperclick-definition-preview
• Strip atom-ide-ui packages of their Nuclide branding.
  • Gracefully migrate commands/keybindings
  • Gracefully migrate CSS styles (Not sure if necessary? depends on open-source themes)

Public launch blockers

• Documentation
  • All public APIs and features should be well-documented.
• Figure out a consistent apm publishing mechanism
  • Set up Lerna to enable easy publishing of atom-ide-ui and its dependencies
• Move repository to "facebook-atom/atom-ide-ui" and sync code from Nuclide.

I have a LS package for Atom for *manifest*.yml files.
Project has manifest.yml file opened in an editor, my LS is started and i can see data tips shown when hovering on keywords provided by atom-ide-ui package.
If I open .classpath file or pom.xml file or any other from the same project (probably any arbitrary file from the project) then my LS for manifest.yml files starts receiving hover requests for stuff from the file opened above which is not the *manifest*.yml file.

I'm getting here server-manager.js getServer(textEditor: atom$TextEditor, projectPath?: string): ?ActiveServer where there is active server for project and hence the message is sent.

Wire up window/showMessageRequest to the Notifications package in https://github.com/atom/atom-languageclient/blob/master/lib/adapters/notifications-adapter.js

Challenges

• Requires bi-directional RPC between the LSP server and client to correctly respond to messages
• Find an LSP server that actually uses this message type

Once a server freezes, we have to disable and enable the package, can we add an atom command to restart language server? I know this might be able to implement in each package, but it's a frequent use case and hoping this is a default behavior.

Issue-izing the TODO found at the autocomplete adapter

When snippet support is implemented, the client should should also advertise this via the client capabilities sent to each language server.

Project and document level symbols are available in the LSP.

Today we have the symbols package in Atom which is heavily tied to ctags and provides no UI of it's own and the outline view in Nuclide which exposes a UI that is not well suited to the data returned from LSP.

Experience

• A shortcut key to toggle the view
• The view by default shows just a document outline
• A second shortcut key to search for a symbol (replaces existing symbol-view shortcut)
• Brings this view in if not currently shown and focuses in the search box selecting all current search text (so it can be easily overwritten/cleared)
• Typing filters the results in the outline view/symbol portion
• Arrow up/down allows user to select a symbol
• Enter goes to that symbol and will also hide the view if it was not previously visible

For workspace either a toggle, additional shortcut or some kind of combined/visual indicator should be considered. TBD.

With my language server implementation, Atom simply sends the initialize and after the server response, nothing happens. I checked against pyls to make sure my response looks as expected, and so far I can't make out any obvious error.

Does atom-languageclient maybe fail to send textdocument/didOpen for the documents opened already at start? Or if not in general, maybe that happens if the language server takes too long before it booted and the delayed promise for createServerProcess() takes too long to get resolved?

In any case, I'm not getting any events for any documents ever, and if I just send textDocument/publishDiagnostics anyway, Atom ignores them..

Right now a package author needs to copy and paste a block of service entries into their package.json even when using the autoadapter.

As we extend the number of services or rename/modify services the user will continually need to keep these up to date by copying and pasting blocks even when autoadapter itself is handling all this communication itself/

I recommend we switch to dynamic registation so that packages automatically take advantage of new IDE features as they are available simply by upgrading their atom-languageclient dependency.

This would also:

• remove a bunch of boilerplate code from the autoadapter into the relevant adapter
• better facilitate adding and removing services dynamically as per LSP v3

Need to determine how these can integrate with Atom.

Right now some linters and language servers return a range length of zero.

We should detect this and highlight the entire word/symbol under the cursor.

Please provide a generic language server plugin built on top of this library to load up any choice of binary as language server, with a UI that is as simple as possible (e.g. which allows to specify any language server binary which the user already has somewhere installed on disk unrelated to the Atom editor install, and the absolute minimal other information required to use it like for example the file extensions to use this language server binary for).

This would easily allow plugging in language servers that don't have native plugins for Atom yet to use them until an official plugin for that language is available.

Formatting code seems to often corrupt the code using both the Java and C# language packages (either via Format File, Format Selection of Nuclide Code Format)

It looks like the end of lines are being cut off. It's possible this is only on Windows and could be CRLF related.

While we're on the subject of document syncing, it appears that renaming a document doesn't send any events :D I think the LSP intends for you to pass these along as a close + re-open with the new URI.

Greetings,

I have installed this package as well as atom/ide-typescript. However when I open a project containing javascript or typescript, nothing seems to happen. Am I supposed to manually start a language server ?

Is there any documentation on how to use this package properly?

Warning: this might be due to a fundamental misunderstanding of node.js / npm on my side.

I tried the following things:

1. I made a new custom package closely following the README.md example code and the java language client atom package
2. I added "atom-languageclient" as dependency
3. I used apm install to install the resulting package

The following happened:

1. The package was copied into ~/.atom/packages/
2. A subfolder was created ~/.atom/packages/<package>/node_modules
3. There is now the dependency atom-languageclient inside ~/.atom/packages/<package>/node_modules/atom-languageclient... but with no "build" folder which the main entry point in the package.json refers to, hence it's unimportable and my package doesn't actually work. Even more confusingly, the atom-languageclient version in that folder also lacks "lib" so running npm run compile . doesn't even allow me to actually build it.

What I expected instead is that apm install would also give me a working copy of atom-languageclient nested inside my custom package attempt so that things actually work.

@damieng if you don't have time to get to this today I think I will, since this is the last blocker for allowing me to dogfood this =D

Auto completion items may not be fully completed during the initial completion request and can be further resolved to fill in the missing details by calling completionItem/resolve.

Challenges

• Autocomplete+ does not have a hook for this right now
• Autocomplete+ would need a new API for this
• Find a language server that requires this

Activate if capabilities.completionOptions.resolveProvider === true

Greetings,

I have installed locally the ide-typescript package as suggested from a previous issue. #62 .
There is one main file in the project lib/main.js. For some reason autocomplete suggestions are delayed tremendously, sometimes 30-45 seconds. There are no errors in the console, so I'm not sure if this is an issue with atom-languageclient or ide-typescript or even an issue with settings / packages I have installed. Are there any known "gotchas" that you could suggest that could be related to the slow loading of suggestions ?

Right now, the README.md contains a short snippet which nicely illustrates how to open up a language client for someone familiar with Atom's plugin system.

However, for someone dropping by who isn't deeply familiar with the plugin system yet, it's not very obvious 1. where this code needs to be put in a plugin, 2. that main needs to be set in the package.json to make it run, 3. that activation hooks need to be set in the package.json and other stuff. In short, it doesn't nicely show to a newcomer how to create the whole minimal package that actually starts and successfully connects to a language server for a new choice of language.

Therefore, I am suggesting the following change:

The README.md should link a minimal complete language client example package right below the example code excerpt, similar to this:

...
module.exports = new OmnisharpLanguageServer()

To see a minimal implementation of this as a complete package, [http://example.com/fill-in-link-here](look at this minimal example package).

Some more elaborate scenarios can be found in the Java LSP package which includes:
...

While linking / mentioning the more elaborate real world examples below helps, they shouldn't replace offering a minimal complete setup showing how to use the library. (IMHO)