Look into proper line ending handling for non-"\n" os's #4

New Issue

2016-09-04T23:25:58+02:00

lspitzner commented

2016-09-04 23:25:58 +02:00

(Migrated from github.com)

If you are a windows/osx users, please point out if brittany's current behaviour regarding newlines needs fixing of any sort.

👍 1

alanz commented

2016-09-05 08:59:14 +02:00

(Migrated from github.com)

Is this a manifestation of https://github.com/alanz/ghc-exactprint/issues/29?

lspitzner commented

2016-09-05 12:02:01 +02:00

(Migrated from github.com)

Yeah it is pretty much the same issue; it is my own fault for unconditionally using \n here though.

Yeah it is pretty much the same issue; [it is my own fault for unconditionally using \n](https://github.com/lspitzner/brittany/blob/master/src/Language/Haskell/Brittany/BackendUtils.hs#L85) here though.

alanz commented

2016-09-05 12:04:37 +02:00

(Migrated from github.com)

Ok, so no action required on ghc-exactprint for this?

lspitzner commented

2016-09-05 12:38:02 +02:00

(Migrated from github.com)

well, yes and no.
First question is where to put input-newline-mode-detection. It kinda makes sense for exactprint's parsing functions to return that info, but that is not required.
Secondly https://github.com/alanz/ghc-exactprint/issues/29 is still relevant for the parts of the input not transformed by brittany which are just restored via exactprint.

well, yes and no. First question is where to put input-newline-mode-detection. It kinda makes sense for exactprint's parsing functions to return that info, but that is not required. Secondly https://github.com/alanz/ghc-exactprint/issues/29 is still relevant for the parts of the input not transformed by brittany which are just restored via exactprint.

Ciantic commented

2017-11-27 15:42:10 +01:00

(Migrated from github.com)

I think this is causing issues on Windows. I'm using vscode with Haskell Language Server, and everytime I format a document it doubles the new lines:

(It uses birttany for formatting)

fib :: Int -> Int
fib 0 = 0
fib 1 = 1
fib n = fib (n - 1) + fib (n - 2)

main = do
  print $ fib 15

becomes:

fib :: Int -> Int

fib 0 = 0

fib 1 = 1

fib n = fib (n - 1) + fib (n - 2)



main = do

  print $ fib 15

I think this is causing issues on Windows. I'm using vscode with [Haskell Language Server](https://github.com/alanz/haskell-lsp), and everytime I format a document it doubles the new lines: (It uses birttany for formatting) ``` fib :: Int -> Int fib 0 = 0 fib 1 = 1 fib n = fib (n - 1) + fib (n - 2) main = do print $ fib 15 ``` becomes: ``` fib :: Int -> Int fib 0 = 0 fib 1 = 1 fib n = fib (n - 1) + fib (n - 2) main = do print $ fib 15 ```

lspitzner commented

2017-11-27 23:47:26 +01:00

(Migrated from github.com)

I'll have to do some testing on windows.

Ciantic commented

2017-11-28 17:54:32 +01:00

(Migrated from github.com)

I can confirm it works with LF, you can switch it in Linux too from status bar in VSCode:

But it fails if I switch to Windows default CRLF:

I can confirm it works with LF, you can switch it in Linux too from status bar in VSCode: ![image](https://user-images.githubusercontent.com/64731/33332648-7a4f3530-d46d-11e7-8dfd-c36605c3a905.png) But it fails if I switch to Windows default CRLF: ![image](https://user-images.githubusercontent.com/64731/33332669-8ae452f4-d46d-11e7-8d92-969bd1fe28de.png)

lspitzner commented

2017-12-07 00:47:22 +01:00

(Migrated from github.com)

@Ciantic I cannot reproduce this particular line-duplication problem, having tested both the brittany executable and the library interface via the test in the brittany testsuite under windows on \r\n encoded input. For the executable, brittany seems to work correctly (i.e. produce \r\n in the output). For the library interface, brittany (incorrectly) produces \n-only output, i.e. brittany replaces \r\n by \n. But no line duplication either.

If you are certain that brittany is at fault, please provide a brittany-specific testcase for reproduction.

@Ciantic I cannot reproduce this particular line-duplication problem, having tested both the brittany executable and the library interface via the test in the brittany testsuite under windows on `\r\n` encoded input. For the executable, brittany seems to work correctly (i.e. produce `\r\n` in the output). For the library interface, brittany (incorrectly) produces `\n`-only output, i.e. brittany replaces `\r\n` by `\n`. But no line duplication either. If you are certain that brittany is at fault, please provide a brittany-specific testcase for reproduction.

afraca commented

2018-08-25 08:03:53 +02:00

(Migrated from github.com)

I just walked into the exact same case as @Ciantic here:
https://github.com/lspitzner/brittany/issues/4#issuecomment-347202072

Using VS Code with the Haskell Language Server extension which claims to be using Brittany for formatting. I started this project with all default settings on Windows, so it was CRLF-ended. When chaning it to LF it seemed to go ok, but I don't know if there's a secret danger to that.

I just walked into the exact same case as @Ciantic here: https://github.com/lspitzner/brittany/issues/4#issuecomment-347202072 Using VS Code with the [Haskell Language Server extension](https://marketplace.visualstudio.com/items?itemName=alanz.vscode-hie-server) which claims to be using Brittany for formatting. I started this project with all default settings on Windows, so it was CRLF-ended. When chaning it to LF it seemed to go ok, but I don't know if there's a secret danger to that.

Sign in to join this conversation.

No Milestone

No project

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: hexagoxel/brittany#4