Fix the gravity output to use the ${OVER} sequence

[rdwebdesign]

What does this PR aim to accomplish?:

The "OVER" sequence CR + ESC[K is not working as expected.

The current code is just replacing the "OVER" sequence with a newline and printing the text after the previous line.

Also, the FTL gravity_parseList() function is sending only a Carriage Return (\r) instead of the full OVER sequence, because the web interface is not a terminal. This prints one very long line with the text of all Progress lines contatenated.

  [i] Processed 1% of downloaded list  [i] Processed 2% of downloaded list  [i] Processed 3% of downloaded list ...

How does this PR accomplish the above?:

The new code fixes this:
When "OVER" is found, the last line on the screen is REPLACED by the new text (like it was in v5).

Link documentation PRs if any are needed to support this PR:

none

---

By submitting this pull request, I confirm the following:

1. I have read and understood the contributors guide, as well as this entire template. I understand which branch to base my commits and Pull Requests against.
2. I have commented my proposed changes within the code and I have tested my changes.
3. I am willing to help maintain this change if there are issues with it later.
4. It is compatible with the EUPL 1.2 license
5. I have squashed any insignificant commits. (git rebase)
6. I have checked that another pull request for this purpose does not exist.
7. I have considered, and confirmed that this submission will be valuable to others.
8. I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
9. I give this submission freely, and claim no ownership to its content.

---

• I have read the above and my PR is ready for review. Check this box to confirm

[DL6ER]

This code has a severe limitation: If \r is found, it actually needs to be the first character or the rest of the code (removing the immediately preceding line) does not make much sense and causes incorrect behavior.

In other words, I could also say that this code really depends on not more than one line being sent at the same time.

This is true in our current API design (each line is immediately pushed as a chunk), but it may be useful to be somewhat more explicit in the code (see additional review comments).

[DL6ER]

Isn't this functionally equivalent to the easier to read/understand

Suggested change

	if (string.indexOf("\r") === -1) {
	if (string[0] !== '\r') {

?

See also my main review comment why I think this is the case.

[rdwebdesign]

They are not the same:

string.indexOf("\r") === -1 will be false if \r is found in the string (in any position).

Your suggestion will be false only if the first character is \r.

var string = "test\r";
if (string.indexOf("\r") === -1) {
  console.log("CR not found");
} else {
  console.log("CR found at "+string.indexOf("\r"));
}

Output: CR found at 4.

Notes:

• In v5 we always sent one line at a time and we still do it.
• we always sent \r as the first character.

[DL6ER]

Sure that, but your example even underlines my point :-)

Assume we already have

abc
def
ghi

and not receive your chunk test\r.

The trailing \r would trigger removing ghi even though this is completely wrong.

With my suggested change, however, the code would not remove ghi and the output would become:

abc
def
ghi
test

IMO this is the correct behavior.

[DL6ER]

This .replaceAll() kinda feels wrong to me but being aware of the one-line-after-another chunking, it is still doing what it should - even when it doesn't feel right (subjective feeling all the way).

[rdwebdesign]

We can create a function to proper cleanup the string, removing "\r�[K", "\r".
We can even allow the use of color codes and replace them with HTML <span> tags with CSS classes to use color output (like we had in v5).

[DL6ER]

Yeah, color codes may be even nicer but it may be over the top. If we want to go entirely crazy we could even make FTL send <span ...> ... </span> already by itself when requesting via the API.

[yubiuser]

Let's not get crazy here... formatting should be done by the receiving/displaying component, not the sending one, I think.

[rdwebdesign]

I could also say that this code really depends on not more than one line being sent at the same time.

Actually that was my assumption, because this was the behavior for v5 and this is the behavior I saw with the current code. We can change that if needed, but: "Do we need to change this?"

To tell the truth, I just adapted the code we currently have in v5.
The main difference is PHP is handling both escape sequences and passing "<-------" to javascript.

In v6 I moved the 2 replace calls to javascript.