3 ms·

That's exactly how LSP is designed. The editor e.g. requests 'the user is hovering over code <here>, what should I show?' and the server responds with some Mark

That's exactly how LSP is designed. The editor e.g. requests 'the user is hovering over code <here>, what should I show?' and the server responds with some Markdown text. Or 'the user wants to navigate to the thing under their cursor <here>, where should I go?' and the server responds with a file/line. Once you try to use LSP for anything not in that form.. it's not so fun.

fiddlerwoaroof 3y ago
No, this is the opposite of how LSP is designed: LSP assumes the editor is looking at a file and this results in a complicated sync dance between editor state and file state. I want the editor to look at temporary buffers served up from the language server and have the code be “written” by sending the temporary buffer back to the language server which handles writing it out to files itself. As far as I know, the only languages with something even vaguely like this are Pharo Smalltalk (with its git integration) and unison
- fiddlerwoaroof 3y ago
  The advantage here is this enables some interesting workflows, like “show me this method and every definition that overrides it in a single view” or “show me this method and all the methods it calls directly”. So you can project the interesting part of your code base into a temporary editor buffer and then edit it and the language server takes care of persistence. Also, it ends the formatting wars because the in-repository format is disconnected from the user’s preferred format.
- zarzavat 3y ago
  > I want the editor to look at temporary buffers served up from the language server and have the code be “written” by sending the temporary buffer back to the language server which handles writing it out to files itself. I don’t think any editor would want to accept this workflow. The biggest issue is that writing is reputation-critical, if the editor writes to the wrong place, or it fails to write when it should have written, then users lose their work which makes them very unhappy. So the editor has to take responsibility for doing the writing, and that is the user’s mental model when they save their work.
  - fiddlerwoaroof 3y ago
    I want a system more like Bank Python[1] or Unison[2] or Pharo Smalltalk[3] that gets us beyond the idea of "code in files". And I have plans to build this on top of Common Lisp + SLIME [1]: https://calpaterson.com/bank-python.html https://calpaterson.com/bank-python.html [2]: https://www.unison-lang.org https://www.unison-lang.org [3]: https://pharo.org https://pharo.org
    - pawelmurias 3y ago
      Loads of people absolutely hate having to use a weird custom IDE just to try a language. That's why all the smalltalk like things are doomed for failure unless they are enforced by a platform.
      - fiddlerwoaroof 3y ago
        Yeah, this is the problem my proposal solves.
- arp242 3y ago
  I don't use LSP for all the real-time stuff, but I do use it for other things like rename symbol, lookup documentation, jump to, etc. and just "the file you have open" isn't really enough for that in most cases. You need to know about the "file layout" or "complete project" for that sort of thing.

fiddlerwoaroof 3y ago

No, this is the opposite of how LSP is designed: LSP assumes the editor is looking at a file and this results in a complicated sync dance between editor state and file state. I want the editor to look at temporary buffers served up from the language server and have the code be “written” by sending the temporary buffer back to the language server which handles writing it out to files itself. As far as I know, the only languages with something even vaguely like this are Pharo Smalltalk (with its git integration) and unison

fiddlerwoaroof 3y ago
The advantage here is this enables some interesting workflows, like “show me this method and every definition that overrides it in a single view” or “show me this method and all the methods it calls directly”. So you can project the interesting part of your code base into a temporary editor buffer and then edit it and the language server takes care of persistence. Also, it ends the formatting wars because the in-repository format is disconnected from the user’s preferred format.
zarzavat 3y ago
> I want the editor to look at temporary buffers served up from the language server and have the code be “written” by sending the temporary buffer back to the language server which handles writing it out to files itself. I don’t think any editor would want to accept this workflow. The biggest issue is that writing is reputation-critical, if the editor writes to the wrong place, or it fails to write when it should have written, then users lose their work which makes them very unhappy. So the editor has to take responsibility for doing the writing, and that is the user’s mental model when they save their work.
- fiddlerwoaroof 3y ago
  I want a system more like Bank Python[1] or Unison[2] or Pharo Smalltalk[3] that gets us beyond the idea of "code in files". And I have plans to build this on top of Common Lisp + SLIME [1]: https://calpaterson.com/bank-python.html https://calpaterson.com/bank-python.html [2]: https://www.unison-lang.org https://www.unison-lang.org [3]: https://pharo.org https://pharo.org
  - pawelmurias 3y ago
    Loads of people absolutely hate having to use a weird custom IDE just to try a language. That's why all the smalltalk like things are doomed for failure unless they are enforced by a platform.
    - fiddlerwoaroof 3y ago
      Yeah, this is the problem my proposal solves.
arp242 3y ago
I don't use LSP for all the real-time stuff, but I do use it for other things like rename symbol, lookup documentation, jump to, etc. and just "the file you have open" isn't really enough for that in most cases. You need to know about the "file layout" or "complete project" for that sort of thing.