Code Monkey home page Code Monkey logo

Comments (12)

rchl avatar rchl commented on September 22, 2024 1

That's likely because your client (Emacs, etc) sends incorrect language ID for those files.

These are the language IDs that should be set for each file type:
js - javascript
ts - typescript
jsx - javascriptreact
tsx - typescriptreact

Previous version of the server was less strict but that likely caused hard to spot issues at a later point.

If you look at the textDocument/didOpen request then you'll see what languageId is being passed.

from typescript-language-server.

AikawaKazuki avatar AikawaKazuki commented on September 22, 2024

I'm experiencing a similar issue with ".ts" files in my Emacs environment using version 4.1.0. When I revert back to version 4.0.0, everything works as expected. I haven't tried ".tsx" files.

Here's the error message I'm receiving:

[server-reply] (id:24) ERROR Mon Nov 13 08:57:20 2023: (:jsonrpc "2.0" :id 24 :error (:code -32603 :message "Request textDocument/documentHighlight failed with message: The document should be opened first: file://[my-file-path]")) [internal] (id:24) ERROR Mon Nov 13 08:57:20 2023: (:message "error ignored, status set (Request textDocument/documentHighlight failed with message: The document should be opened first: file://[my-file-path])" :id 24 :error -32603)

from typescript-language-server.

Waqar144 avatar Waqar144 commented on September 22, 2024

@rchl Is there a reason the server can't infer this on its own? It does have the file name after all.

from typescript-language-server.

rchl avatar rchl commented on September 22, 2024

It would in theory but what would the point of the languageId specified in the LSP spec be then? Why should the server try to fix client or user errors? Especially since it should be easily fixable on the client side.

from typescript-language-server.

Waqar144 avatar Waqar144 commented on September 22, 2024

In Kate, we have work around a lot of issues that are actually server issues because we don't have much of a choice besides letting it fail and let the user suffer.

My point is that rather than breaking perhaps a better idea is to keep a fallback. This matters for some clients like us because we ship once in 4 months. If a server breaks in between releases like this, then an average user is just stuck with a broken server till the next release. Oh and if you are on UbuntuLTS or something like that, then good luck.

from typescript-language-server.

rchl avatar rchl commented on September 22, 2024

Oh and if you are on UbuntuLTS or something like that, then good luck.

Though neither Kate nor this server are part of Ubuntu so that shouldn't really be relevant. :)

I will look into adding a fallback when languageId is wrong.

from typescript-language-server.

Waqar144 avatar Waqar144 commented on September 22, 2024

Its not a part of Ubuntu, but it is installable on Ubuntu. Thanks for listening :)

from typescript-language-server.

joaotavora avatar joaotavora commented on September 22, 2024

Hello,

That's likely because your client (Emacs, etc) sends incorrect language ID for those files.
These are the language IDs that should be set for each file type:

Where is a client author to get this information from? This thread? Or is it some universal information published somewhere.
Is this for all TS servers or just this one? My Eglot client has been providing tsx and js for a long time and it has always worked.

It would in theory but what would the point of the languageId specified in the LSP spec be then?

I assume it's for when files exist in a given language have non-standard extensions so the server can't possibly guess from.

Especially since it should be easily fixable on the client side.

Not really: the client often doesn't know much more about the file's intented language than the server. If
anything, it knows less (the server is the language specialist who could look at the file's contents).

Also this leads to hardcoding things on the client side, which at least my client specifically avoids (it works with hundreds of LSP servers and virtually no server-specific code).

But I see you've already pushed a commit that fixes this, at least for the time being.
So thanks.

from typescript-language-server.

rchl avatar rchl commented on September 22, 2024

Where is a client author to get this information from? This thread? Or is it some universal information published somewhere.

The official spec lists those relevant to this server at least: https://microsoft.github.io/language-server-protocol/specification#textDocumentItem

Is this for all TS servers or just this one? My Eglot client has been providing tsx and js for a long time and it has always worked.

Previously the server didn't validate language ID but then the tsserver would receive wrong languageId and not be able to tell the type of the code apart and likely result in some things not working as expected.

Not really: the client often doesn't know much more about the file's intented language than the server. If anything, it knows less (the server is the language specialist who could look at the file's contents).

Also this leads to hardcoding things on the client side, which at least my client specifically avoids (it works with hundreds of LSP servers and virtually no server-specific code).

The client should know the syntax of the file and thus the language type. Clients should maintain a mapping from syntax/scope to languageId.

While it might not apply so much to this server since this one is geared towards normal files, many servers can work on unsaved files that don't have extension and then the only way to tell the language of the file is with the syntax/languageId.

So relying on file extension alone is not reliable.

from typescript-language-server.

joaotavora avatar joaotavora commented on September 22, 2024

The official spec lists those relevant to this server at least: https://microsoft.github.io/language-server-protocol/specification#textDocumentItem

Thanks, I missed this.

from typescript-language-server.

leia-uwu avatar leia-uwu commented on September 22, 2024

In Kate, we have work around a lot of issues that are actually server issues because we don't have much of a choice besides letting it fail and let the user suffer.

My point is that rather than breaking perhaps a better idea is to keep a fallback. This matters for some clients like us because we ship once in 4 months. If a server breaks in between releases like this, then an average user is just stuck with a broken server till the next release. Oh and if you are on UbuntuLTS or something like that, then good luck.

yeah i use kate and had to downgrade and ignore upgrades for the typescript-language-server package on arch because of this update :/

from typescript-language-server.

leia-uwu avatar leia-uwu commented on September 22, 2024

oh nvm i just saw that the fix just requires editing the LSP config, also made a pr to fix lol

from typescript-language-server.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.