Formatter should return a single edit

[ramya-rao-a]

At present, when there is a formatting request 2 edits are returned. 1 to clear all text in the file, another to add back the formatted content. These can be merged into a single edit. This will fix the issue of the cursor moving to the end of the file/range in VS Code

cc @keegancsmith @slimsag

[lloiser]

I think this is fixed with #83.

[keegancsmith]

It would be fixed by #83, but it needs to be picked back up. I was having issues with how it behaved at end of file last time I tested it which I couldn't resolve. It would be good if someone tried out that PR in vscode-go and see how it behaved.

A range in a text document expressed as (zero-based) start and end positions. A range is comparable to a selection in an editor. Therefore the end position is exclusive. If you want to specify a range that contains a line including the line ending character(s) then use an end position denoting the start of the next line.

@ramya-rao-a Doing a single range is probably part of what I was having trouble with in #83. If I want to do the whole file the LSP spec implies I find the last line, then I should set end to { line: lastline+1, character: 0 }. However, I remember vscode not liking that. Maybe I was doing something wrong, or it is an old bug that is fixed now. But does lastline+1 sound correct to you?

[ramya-rao-a]

@dbaeumer should be able to confirm that

[dbaeumer]

@keegancsmith since the last line has no line ending character (it is the last line) lastLine + 1 points to an invalid line. I agree that VS Code could handle the case more gracefully in a replace edit that otherwise spawns the whole file.

[keegancsmith]

@dbaeumer so the whole document range is

start: {line: 0, character: 0}
end: {line: lastline, character: len(doc[lastline])}

?

what do you put if the file has more than one trailling new lines? Would character be 0 since the last line is empty?

[dbaeumer]

Yes, that sound correct to me.