Line wrap issue when spider.js outputs its progress indicator to tty

[kyle0r]

Background knowledge: A terminals dimension units are: rows (height) and columns (width), you can see the actual values with the command: stty size - The first value is the rows, followed by columns. Note that these dimensions change when the terminal is resized.

The terminal's linewrap capability, aka automargins can be controlled with setterm --linewrap on|off, which outputs a character string to stdout, to invoke/toggle the linewrap capability.

An alternative way is: off: tput rmam and on: tput smam

The escape code for line wrap appears to be off: <ESC>[7l and on: <ESC>[7h

Further reading: search for automargin in man terminfo

---

Expected behaviour: spider.js progress indicator should not cause the terminal cursor to move from its current row (line).

Actual behaviour: If terminal line-wrapping capability (automargins) is turned on AND the progress indicator output is greater than the terminal width (columns), the progress indicator output is wrapped onto the next line (row), which is contrary to the original design of a single line progress indicator.

The original design of the spider.js progress indicator was to provide a visual indication of the spidering/crawling progress of the provided URIs.
Motivations: Show the user that something is happening, and help them to spot any obvious bad status codes like 401 Unauthorized, or any obvious unwanted URI's being crawled.

I had not tested what happens when the progress indicator output is wider/longer than the number of columns in the tty. 🤦

If terminal is configured to linewrap, and subsequently wraps the output because its length is greater than the value of tty columns, this will move the terminal cursor to the next line (row).

The current progress output logic does not track the row and column coordinates, it simply moves the cursor to the start of the current line (row), truncates any output, and writes the next output.

Once the cursor has moved (wrapped) to the next line (row), one could argue that it is already too late, because now the scrollback has also also been effected.

At the moment, I think the most effective solution is to turn off the terminal line-wrapping capability via the escape code (not forgetting to turn it back on again). Studying various terminal documentation resources suggests that the escape code for line-wrapping aka automargins is consistent across the many terminals.

Q: Would wrapping the progress indicator output with the off then on line wrap escape sequence be performant? Measurement required. This approach would have the advantage of being atomic-like (off and on in single output) and not having to worry about turning line wrapping back on later, or having to capture the terminal state before to running spider.js and then having to restore the terminal state later, or having to reset the terminal.

Q: It might be sufficient to turn off line wrapping once before / at the start of spider.js and then turn on once at the end / after.

Q: If spider.js is being executed directly (not via recursive-downloader shell script), the progress indicator should probably be disabled?