Fix extra newline being added when formatting document #525
Conversation
@@ -44,7 +46,8 @@ brittanyCmd tabSize uri range = | |||
l = length textLines | |||
c = T.length $ last textLines | |||
textLines = T.lines text | |||
textEdit = J.TextEdit (Range startPos endPos) newText | |||
newTextWithoutNewline = T.init newText -- get rid of extraneous \n |
wz1000
Apr 13, 2018
Collaborator
Wouldn't it be a better idea to remove all trailing newlines specifically instead of blindly truncating the text?
Wouldn't it be a better idea to remove all trailing newlines specifically instead of blindly truncating the text?
bubba
Apr 13, 2018
Author
Collaborator
Probably! Brittany seems to only remove the first trailing newline though, so should we try to match this?
Probably! Brittany seems to only remove the first trailing newline though, so should we try to match this?
The use of @bubba Unrelated: Under what circumstances does brittany remove trailing newlines? |
@lspitzner I was mistaken, brittany doesn't seem to remove newlines at all. Prelude T> x = T.pack "hello\r\nworld"
Prelude T> T.lines x
["hello\r","world"] But this bug happens regardless of the line encoding used. > cat test
hello world
this is a test with no newline Prelude T> readFile "test"
"hello world\nthis is a test with no newline\n" |
@lspitzner what do we do with this PR? |
I cannot reproduce the issue with
I also point out that it is really hard to tell from
whether the file actually terminates with a newline. It really should look like this:
|
As this might be system/locale dependent, I should add that I have tested on linux only, with "\n" and "\r\n". @bubba what environment are you seeing this in? |
Sorry, disregard what I said about |
What I'm now convinced was happening is that the range of text being replaced didn't include the last newline character, which meant that it stayed around after the formatted text was inserted, adding an extra line. From the specification:
Although I found that the end range column needs to be past zero, contradictory to above. This was tested on VS Code. |
The Position type is zero indexed(as specified by LSP), but the tuple (Int,Int) is assumed to always be one indexed in HIE(as GHC reports positions as one indexed tuples).
The mixing of types here is unfortunate(probably my fault, and how this bug originated). It would be better to use one of these position types consistently here. Otherwise it looks good. |
@wz1000 It all makes sense now, pushed a change for that! |
@wz1000 when you are happy, please merge this. |
Fixes #521