LSP Intro + Language Servers Aren't Just For Languages

แชร์
ฝัง
  • เผยแพร่เมื่อ 15 พ.ย. 2024

ความคิดเห็น • 24

  • @semanticart
    @semanticart  10 หลายเดือนก่อน +2

    What parts of the LSP or Language Servers do you find confusing?

  • @gemini_537
    @gemini_537 7 หลายเดือนก่อน +3

    This is informative! But I wanted to confirm that to add the support for a particular framework/tool, it requires several things: 1) adding a capability; 2) implementing the capability in both the IDE and the server side. Is my understanding correct? There seems to be a lot of work.

    • @semanticart
      @semanticart  7 หลายเดือนก่อน +4

      If you're implementing functionality covered by the LSP, then you shouldn't have to implement any functionality in the IDE (if the IDE/editor already supports the LSP -- many do). You should only have to implement the functionality in your language server and all LSP-enabled editors can use it for free.
      If you're implementing custom functionality, then yes, you'll need to implement things in both your language server and some glue code per IDE. That's non-trivial for sure, but putting the functionality in a language server means you get to re-use that for every editor and just have to handle the glue code for the editors.
      This is much less work than implementing ALL the functionality (both the UI and backend code) in each editor. :)
      I have a video where I look at a ruby-lsp custom method that only has support in VS Code and implement the glue code for neovim. You can check it out here: th-cam.com/video/8_u0Fvtq_ew/w-d-xo.html

  • @pedrorodriguez2683
    @pedrorodriguez2683 10 หลายเดือนก่อน +4

    Great video!

    • @semanticart
      @semanticart  10 หลายเดือนก่อน

      Thanks so much, Pedro! I'm glad you enjoyed it

  • @jonathanlevin7660
    @jonathanlevin7660 10 หลายเดือนก่อน +2

    Ive always been curious about the LSPs and how theyre implemented, particularly whether theyre the reason VScode seems to lag a bit before recognizing you're above some text that can be acted upon! (Compared to Jetbrains editors which are fairly instant).

    • @semanticart
      @semanticart  10 หลายเดือนก่อน +1

      There are many reasons for lag but it definitely could be a misbehaving language server. What languages are you working with?
      Related: The LSP making tools reusable across editors is such a win that even Jetbrains is _slowly_ dipping their toes into LSP support: blog.jetbrains.com/platform/2023/07/lsp-for-plugin-developers/

    • @jonathanlevin7660
      @jonathanlevin7660 10 หลายเดือนก่อน

      @@semanticart thanks for the reply! In vscode mostly JS/TS. It may be an unfair comparison since I mostly use Jetbrains Rider for C#, which I assume has good tooling OOTB with roslyn.
      But I noticed that if I start typing fast (even for a language keyword, like 'await') if I hit tab before the suggestion dropdown comes up, it will simply input a tab. But if I wait an extra few hundred millis- the dropdown will appear and a tab will input 'await'. Maybe its just an editor setting?

    • @semanticart
      @semanticart  10 หลายเดือนก่อน

      🤔 It might be an editor setting but I don't know what it would be off-hand. I'm sadly not a VS Code expert.
      But using VS Code on a typescript project locally, I can't type fast enough to hit "aw" + tab and not get `await` completed.
      Is the behavior different on a very small example project?

  • @realvatican
    @realvatican 18 วันที่ผ่านมา

    Could you make an lsp client from scratch. Your teaching style is excellent and I cannot find any tutorials for the other way round

  • @semanticart
    @semanticart  10 หลายเดือนก่อน +1

    What's your favorite language server?

  • @minma02262
    @minma02262 2 หลายเดือนก่อน

    You are my God.

    • @semanticart
      @semanticart  2 หลายเดือนก่อน +1

      I'm just a dude. Thanks for watching.

  • @eazypeazy8559
    @eazypeazy8559 7 หลายเดือนก่อน

    cool!

    • @semanticart
      @semanticart  7 หลายเดือนก่อน +1

      Thanks! Have a great day

  • @lack_of_awareness
    @lack_of_awareness 9 หลายเดือนก่อน +1

    LSPs are nice, but man the API to write one is so dogshit

    • @semanticart
      @semanticart  9 หลายเดือนก่อน +1

      Can you be specific? I haven't found it painful.

    • @lack_of_awareness
      @lack_of_awareness 9 หลายเดือนก่อน

      @@semanticart I’m not sure how to accurately describe it, but I would say bloated and overly convoluted? Like if I just want to show a list of autocompletion items there’s so much boilerplate that gets in the way of just writing the basic logic

    • @lack_of_awareness
      @lack_of_awareness 9 หลายเดือนก่อน +1

      Also trying to make a vscode extension and link the LSP to it is also a whole other mess. I would much rather prefer a simplistic api that I can incrementally build up the complexity as needed instead of having to specify 100+ different things at once

    • @semanticart
      @semanticart  9 หลายเดือนก่อน

      @@lack_of_awareness I think you can do things pretty incrementally by only adding the things you want to support in the server capabilities. In my th-cam.com/video/Xo5VXTRoL6Q/w-d-xo.html video, we build out initialization, document synchronization, and completion in about an hour (and that includes rolling our own stdin/stdout JSON-RPC message parsing).

    • @lack_of_awareness
      @lack_of_awareness 9 หลายเดือนก่อน +1

      @@semanticart ah yeah I saw that video before it was great. Do you have a video on how to actually use the LSP in a vscode extension? All the guides & templates for language server extensions in vscode are a mess