TextDocumentContentChangeEvent#rangeLength redundant?

[svenefftinge]

It seems like 'rangeLength' is redundant, as it can be computed from the 'range'. Should be deprecated.

[svenefftinge]

DidChangeTextDocumentParams could maybe reuse TextEdit

[dbaeumer]

Agree, but the reason we sent this is to avoid unnecessary work on a server which has a [offset, length] text model instead of a [[startLine, startColumn], [endLine, endColumn]] model.

[dbaeumer]

Will look if it makes sense to reuse TextEdit

[kdvolder]

Okay so I get that it might be convenient to include redundant info. However, the fact that its redundant also makes it a little unclear what the expectations are from client/server point of view. In particular, is it okay for a client to only specify range but not rangeLength (since the info is redundant, if client didn't feel like computing it, the client implementor might assume that this is okay and the server must deal with that).

I see two possible interpretations depending on who's point of view we take re 'convenience' here:

1. Point of view favoring convenience of server implementations:

client: MUST set both range and rangelength even though rangelength is redundant.
server: MAY ignore rangelength or 'end' posisition of the range, whichever is more convenient.

2. Point of view favoring the convenience of client implementations:

client: MAY optionally set rangelength but may ommit this redundant piece of information if it wishes.
server: MUST be able to handle it when optional rangelength is missing (by computing it from the range, if they need it).

My guess is that the intention here is to use the first interpretation (based on what was said earlier, which implies this is for the convenience of server implementation). Whether I'm guessing it right or not... it would be good to make this very clear in the Spec.

Alternatively, maybe its just easier / better avoid this complexity in the Spec and just deprecate/remove the redundant rangeLength. Everything in LSP protocol is already in terms of line/col posititions so this is a bit of a weird deviation from that anyhow. And since a lsp-server that uses a 'offset-based' model instead of line/col will already need to keep a table to convert between them, it doesn't really seem to make a lot of difference if the server has two positions to convert instead of one.