Request for assistance with line break issue and potential feature modification

[marcglasberg]

I just noticed today that while typing strings or comments in the editor, the code seems to break automatically during the editing process. This behavior appears to have started after I switched to using LF instead of CRLF on Windows. Or maybe it's a new feature just recently introduced, altogether?

The automatic line breaks can be quite challenging to work with, especially when I add and then need to delete something and the rest of the text doesn't return to its original position. The result is a half-full line that looks odd. I understand that the intention behind this feature might be to assist users, but it can be counterproductive in certain scenarios.

In addition, I'd like to have control over how my code is formatted, including when and where strings break. I appreciate any efforts to make the editing experience smoother, but it's essential to have the flexibility to format my code as I see fit.

Could you kindly let me know if there's an existing option in the settings to disable this feature? If there isn't, I'd like to request that this feature either be removed or modified to allow users to opt-out. Additionally, it would be beneficial for future features to include the option to enable or disable them, giving users more control over their editing experience.

Apologies if I've overlooked an existing opt-out setting related to this issue. Your guidance on this matter would be greatly appreciated.

Thank you.

[stevemessick]

I doubt it is a new feature; I'm not aware of any work in that area. I'm curious why you would use LF instead of CRLF on Windows? That's likely to break any number of things. I think there is some hard-coded reliance on CRLF in the Dart plugin.

However, the Flutter plugin doesn't do anything to control line breaks while typing. That's all done in the Dart plugin.

There's a discussion about formatting in the Dart plugin issue tracker.
https://youtrack.jetbrains.com/issue/WEB-45838/Dart-formatter-reinstate-ability-to-opt-out-of-dartfmt

Also, this issue has some potentially relevant info.
dart-lang/sdk#51911

[marcglasberg]

@stevemessick Here is why we changed all our files to LF:

#3255

[alexander-doroshko](https://github.com/alexander-doroshko) commented [on Nov 29, 2022]

Hi from JetBrains. We now know that the weird highlighting after save is related to CRLF line endings.
image

Note that this is not connected with slow completion or whatever else discussed here. It's a separate isolated bug.

I haven’t managed to reproduce it so far so I can't say for sure where the bug is. Let's track it in the Dart plugin issue tracker: https://youtrack.jetbrains.com/issue/WEB-56916.

The workaround is to switch to LF line endings. The widget in the IDE status bar allows to do it easily per file (any OS). IDE also allows to change line separators for a specific folder of for the whole project (Find Action -> Line Separators).

So now there's one less problem to track within this issue.

What kind of problems will we get with CRLF? What number of things that's likely to break?

[marcglasberg]

When you say this:

However, the Flutter plugin doesn't do anything to control line breaks while typing. That's all done in the Dart plugin.

Sorry, but I don't know the difference between Flutter plugin and Dart plugin, could you explain it to me please? When you say Dart plugin, do you mean dartfmt? Or is it something else?

---

Just to be clear, suppose I have the IDE allowing 100 char lines, and this code:

    var text = "Lorem ipsum consectetur adipiscing elit, sed do eiusmod tempor incididunt ut";

If I put the cared after the word ipsum and I type dolor sit amet it changes the code while I type, to this:

    var text = "Lorem ipsum dolor sit amet consectetur adipiscing elit, sed do eiusmod tempor "
        "incididunt ut";

If then I change my mind and remove the words dolor sit amet the end result is this:

    var text = "Lorem ipsum consectetur adipiscing elit, sed do eiusmod tempor "
        "incididunt ut";

In other words, it did not go back to the previous text in a single line. Now I have an useless extra line.

I don't think this is related to dartfmt as this line breaking change is happening as I type. Also, the rest of the code is not being formatted. So it seems to be the IDE doing it. Also, I just tested changing the file to CRLF and the it's still breaking as I type.

Please, help me. Who should I talk to so that I can turn this off?

[stevemessick]

Sorry, but I don't know the difference between Flutter plugin and Dart plugin, could you explain it to me please? When you say Dart plugin, do you mean dartfmt? Or is it something else?

The Dart plugin was created by JetBrains shortly after the Dart language was announced. It helps with Dart programming, but knows nothing about Flutter. The Flutter plugin was created shortly after Flutter was started specifically to help with Flutter tasks. When you set up a new Android Studio or IntelliJ IDE to work with Flutter the first thing you do is install the Dart and Flutter plugins.

The formatter dartfmt is part of the Dart SDK. It is used to format Dart code. It does not run automatically as you type, but you can configure your IDE to invoke it when you save a file. Automatic line breaks, such as you describe in your example, are handled by the Dart plugin. It also determines the indent level when you type a newline. You may have noticed that it sometimes gets the indent level wrong, and when the file is formatted by dartfmt it will change.

I have not tried this, but I believe that you could disable the Flutter plugin, then create a pure-Dart project, and repeat the example you described. You should see the same behavior. There's a link to the Dart issue tracker in my previous comment.

I don't know if there is a way to disable this behavior. You could check Settings > General > Smart Keys to see if anything there can help.

What kind of problems will we get with CRLF? What number of things that's likely to break?

I have not used Windows lately, so perhaps it has become more accepting of alternate line endings, but most programs used to handle non-standard line endings incorrectly. Back then, Macs used CR as line terminators. If I coped a file from Mac to Windows and opened it in an editor, it was unreadable because everything was printed on a single line.