[feat] Add --wrap n option to change the length at which lines get wrapped

[cdesaintguilhem]

It could be nice to let the user choose the length at which lines get wrapped, with the default remaining 80 as it is now, and --wrap 0 being the equivalent of --keep.

[WGUNDERWOOD]

Yes this is a good suggestion, I will work on it soon!

[WGUNDERWOOD]

Implemented in a6177f0, let me know if it works as expected. Thanks for your helpful suggestions!

[cdesaintguilhem]

It works as expected! (Including with the recent ability to customise parameters to tex-fmt inside LaTeX-Workshop on VS Code, see this PR)

Thanks for implementing this so quickly!

It doesn't wrap as tightly to the 120-character rule as the Rewrap extension for VS Code, but that's maybe due to the minimum line length setting. And I understand that you're using the -10 offset to have some margin when wrapped lines need indenting after wrapping, and changing that might require something like multiple passes over the same block of lines and could introduce further bugs.

[WGUNDERWOOD]

That's right, see #6 for a discussion of this. I should mention that I'm not sure that --wrap 0 should be equivalent to --keep, as typically reducing --wrap implies shorter lines. So I propose we just maintain the --keep flag for this separately.

[cdesaintguilhem]

I wonder if there could be a dynamic "minimum length" which takes into account the current indent of the line that is being wrapped... I'll have a think to see if I can come up with a working idea.

Maintaining --keep makes sense to me.

[WGUNDERWOOD]

The problem is that where you choose to wrap the line also affects the indentation level (you might wrap it before a closing bracket, for example).

[cdesaintguilhem]

Ah yes indeed. One (not so nice) solution would be to do several local iterations. (I say this without knowing how the initial multi-pass framework was implemented.)

My thought is: when a line should be wrapped, split it into several lines and queue them all for re-indentation. As the code iterates through the queued lines, it corrects the indentation if need be, and if that requires wrapping again, then it merges the trailing word(s) with the next line on the queue (if there is one), computes the new wrapping point, and submits the remaining line for re-indentation (if there is one). This feels like it should converge to a stable combination of indentation and tight wrapping, but feeling never takes care of all the edge cases.

[WGUNDERWOOD]

This is almost what the current implementation does, with a queue of lines which require processing (possibly multiple times), but without merging trailing words. This would require us to keep track of where line breaks are in the original file too, and I think this is a little complicated for now. I'll close the issue since I fixed the main request of the --wrap flag, but will keep these ideas in mind.