atom / atom-languageclient Goto Github PK
View Code? Open in Web Editor NEWLanguage Server Protocol support for Atom (the basis of Atom-IDE)
Home Page: https://ide.atom.io/
License: MIT License
Language Server Protocol support for Atom (the basis of Atom-IDE)
Home Page: https://ide.atom.io/
License: MIT License
Warning: this might be due to a fundamental misunderstanding of node.js / npm on my side.
I tried the following things:
apm install
to install the resulting packageThe following happened:
~/.atom/packages/<package>/node_modules
~/.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.
AutomComplete+ suggestion has descriptionMarkdown
property that can accept MarkDown format documentation for completion proposals.
Here is the PR: #69
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,
Wire up window/showMessageRequest to the Notifications package in https://github.com/atom/atom-languageclient/blob/master/lib/adapters/notifications-adapter.js
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.
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..
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 ?
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.
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.
atom-ide-ui
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.
The textDocument/hover api allows additional information about a section of the document to be displayed in a hover/tool-tip style fashion.
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.
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
.
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.
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.
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.
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.
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.
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)
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.
I think this can make an option since autocomplete in atom cannot complete parameters in the fly like vscode.
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
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.
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?
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.
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.
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.
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.
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?
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.
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.
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.
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?
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.
Activate if capabilities.completionOptions.resolveProvider === true
@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
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?
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.
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?
Need to determine if and how this could integrate into Atom.
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:
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.
For workspace either a toggle, additional shortcut or some kind of combined/visual indicator should be considered. TBD.
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
?
Need to determine how these can integrate with Atom.
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.
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.