Re: [code] [textadept] New Language Server Protocol client module

From: Mitchell <>
Date: Mon, 1 Oct 2018 16:50:55 -0400 (EDT)

Hi Chris,

On Sun, 30 Sep 2018, Chris Emerson wrote:

> Hi Mitchell,
> On Sun, Sep 30, 2018 at 09:29:25PM +0100, Chris Emerson wrote:
>> On Mon, Sep 17, 2018 at 09:27:16PM -0400, Mitchell wrote:
>> The attached rough patch (against b5beae87e409, or at least that's the name
>> of the ZIP file I got from hg) gets through that, though might not do it
>> the best way. The changes are:
>> 1. The 'initialized' message seems to need an empty object rather than
>> nothing. Otherwise the RLS returns an error.
>> 2. The lines come back with \r\n line endings, and the lines end up with
>> '\r' at the end and don't match the "Content-Length" pattern, plus
>> `#line > 0` is always true.
>> I haven't yet worked out how to get information out of it, but at least
>> it doesn't hang on opening a Rust file now. :-) I use
>> `_M.lsp.server_commands.rust = 'rls'` after installing it.
> I've had a further look. It's partly working - occasionally I get some
> diagnostics showing as annotations, which is excellent! I've also successfully
> used the "jump to definition" and similar commands.
> I think I'm hitting a couple of issues which means it's not yet reliable:
> * If Server:handle_stdout gets more than one message, then it was losing the
> next one, because the recursive call was eating the 'C' of 'Content-Length'
> from the next message. I "fixed" that by removing the "+ 1"; I'm not sure
> if that's right, or whether it's just cancelling out a bug in my previous
> patch where I just remove '\r' characters.

Try with a more recent build of Textadept (e.g. 10.1). I think this will go away.

> * I've seen notifications from the server being split across reads (e.g.
> the "Content-Length: 1234\r\n\r\n" in one read, and the actual message in
> the next). I can see that's not handled yet.

Yeah, there's a TODO around line 286 for handling split messages properly via some sort of buffering. Since the LSP module isn't expecting notifications, it passively reads in stuff and tries to interpret it in a simplistic way. Thus, notifications from servers like diagnostics will probably not work 100% of the time. In my testing and usage though, anything you ask of the server (completions, goto definition, etc.) will work all of the time without getting split messages.


You are subscribed to
To change subscription settings, send an e-mail to
To unsubscribe, send an e-mail to
Received on Mon 01 Oct 2018 - 16:50:55 EDT

This archive was generated by hypermail 2.2.0 : Tue 02 Oct 2018 - 06:29:30 EDT