Fixed inconsistent CR/LF

[MadQ]

• 2 lines used "\n\r" instead of "\r\n". Consistent use of "\r\n" will allow the Configurator CLI code to be simplified.

• This PR is in preparation for some changes and enhancements in the Configurator CLI that I am currently working on.

• The Configurator CLI code currently has code that is interned to treat carriage returns and line feeds differently, depending on the CR/LF semantics of the operating system. This is actually irrelevant because the firmware CLI code is entirely agnostic about those semantics, and also treats CR and LF identically when processing input characters.

• This change makes it easier for the Configurator CLI to process serial reads in chunks, instead character by character, which dramatically reduces CPU usage. On the very old laptop I am currently using, a dump all can take up to 20 - 30 seconds, but is near instantaneous when processing serials reads in chunks.

[McGiverGim]

Good catch!!

[McGiverGim]

The only strange thing is that we have three commits for that. Are you able to squash and update the PR?

[mikeller]

Good catch.

Never do the line feed before the carriage return - somebody who has practical experience in why ;-)

[mikeller]

@MadQ:

The Configurator CLI code currently has code that is interned to treat carriage returns and line feeds differently, depending on the CR/LF semantics of the operating system.

This was done way back when, before there were buttons to save / load the contents of the CLI, to make it possible for users of different operating systems to copy / paste CLI contents without getting them garbled.

These days we could probably do away with it, and do the translation to / from the native line break style in the save / load implementations.

[MadQ]

The only strange thing is that we have three commits for that. Are you able to squash and update the PR?

Yes, I can. As soon as I figure out how. This is my first GitHub PR ever. I swear this this kind of stuff was easier to learn when I was 20 years younger.

[MadQ]

The Configurator CLI code currently has code that is interned to treat carriage returns and line feeds differently, depending on the CR/LF semantics of the operating system.

This was done way back when, before there were buttons to save / load the contents of the CLI, to make it possible for users of different operating systems to copy / paste CLI contents without getting them garbled.

These days we could probably do away with it, and do the translation to / from the native line break style in the save / load implementations.

Correct. The Configurator CLI already translates "\r\n" to <br> tags, which the DOM innerText property of the <pre> element (used for copy and save) handles correctly. I.e. the <br>s are converted to the OS's flavor of line breaks (AFAIK).

(Just bringing this up for discussion) So that also begs the question... does anyone still use a direct serial connection or telnet to the FC instead of using Configurator? I'm guessing the answer might be "Yes", but if not, we could probably do away with the VT stuff, like the handling of backspaces, <CTRL>+D, and VT sequences to clear screen/line, etc., and simplify the auto-completion on TAB.
The only other application I have used is an Android app on my phone, but it only uses line-mode, and is not really a VT.

On second thought, this might be opening too big a can of worms.

[mikeller]

(Just bringing this up for discussion) So that also begs the question... does anyone still use a direct serial connection or telnet to the FC instead of using Configurator? I'm guessing the answer might be "Yes", but if not, we could probably do away with the VT stuff, like the handling of backspaces, +D, and VT sequences to clear screen/line, etc., and simplify the auto-completion on TAB.
The only other application I have used is an Android app on my phone, but it only uses line-mode, and is not really a VT.

On second thought, this might be opening too big a can of worms.

Definitely can of worms. One use case to consider is the one of developers working on the firmware - most of them (myself included) will have configurator side autocompletion disabled, as it does not play well with new commands or ones added temporarily for debugging, and the auto-detection run when opening the CLI tab often interferes with testing. So removing all of the smarts from the firmware and expecting the CLI to fill in will most likely make the lives of this group harder.