New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Newline added on every save #289

Closed
ismailmustafa opened this Issue Aug 16, 2017 · 8 comments

Comments

Projects
None yet
4 participants
@ismailmustafa
Contributor

ismailmustafa commented Aug 16, 2017

In VSCode every time I make a change to a file and save it, a newline is added to the end of the file. Assuming you make 100 changes and save after every change, this will result in 100 empty lines added to the end of the file.

@wz1000

This comment has been minimized.

Collaborator

wz1000 commented Aug 18, 2017

I can't reproduce this. Anyway, it sounds like an issue with vscode, not HIE. Maybe make an issue on the vscode tracker?

@ismailmustafa

This comment has been minimized.

Contributor

ismailmustafa commented Aug 18, 2017

I thought this was the case however I can only reproduce this when using HIE. Two cases that hint at HIE being the issue:

  1. The problem only occurs on files with the .hs extension.
  2. Uninstalling HIE fixes the issue.
@sheyll

This comment has been minimized.

sheyll commented Sep 9, 2017

I have the same issue, I think it happens when editor.formatOnSave and files.insertFinalNewline are both true.

I think Brittany indents a final newline, such that the former final newline isn't regarded as the final newline anymore, and a new final newline is inserted by vscode next time the buffer is saved, which then gets indented by brittany, and the cycle repeats...

@ismailmustafa

This comment has been minimized.

Contributor

ismailmustafa commented Sep 10, 2017

Good catch! files.insertFinalNewline is set to false for me. But setting editor.formatOnSave to false seems to fix the issue. It looks like this open issue on the Brittany issue tracker might be related lspitzner/brittany#25.

@lspitzner

This comment has been minimized.

Contributor

lspitzner commented Sep 10, 2017

lspitzner/brittany#25 has nothing to do with this.

I think @sheyll's analysis is close, although I am confused where the newline containing space comes from.

It is true that brittany adds a new line if the last line contained anything in the input (even if those contents were only spaces that don't get reproduced by brittany). But this stops after one iteration, as there now is a newline character at the end of the input. So idempotency is not violated from brittany's end alone.

There are two fixes to this: Stop brittany from adding a final newline and stop whatever else from adding a line containing space. I think both should be implemented. I have opened lspitzner/brittany#53.

@lspitzner

This comment has been minimized.

Contributor

lspitzner commented Sep 10, 2017

As it turns out, lspitzner/brittany#53 was unrelated, although it had a similar cause. Brittany never exposed any newline-appending behaviour when the ppconf_hackAroundIncludes config value was set to False, which it was when called via HIE.

But I think the cause is related: the plugin uses Text.lines instead of Text.splitOn "\n". The issue boils down to T.lines/T.unlines not forming a bijection. (The same holds for List.lines/unlines.)

So now I think the fix involves not using T.lines (although splitOn might also require further changes, as splitOn and unlines don't form a bijection either) and not appending a final line containing space.

@sheyll

This comment has been minimized.

sheyll commented Apr 6, 2018

Any update on this?

@ismailmustafa

This comment has been minimized.

Contributor

ismailmustafa commented Apr 18, 2018

Fixed with #525

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment