Retain TAB (`\t`) information on screen to recreate TAB on copy

[christianparpart]

This came out as a consequence of #982. But #982 should focus on retaining lost spaces (which is a bug to be fixed)

This is about explicitly adding the feature to retain any written TAB character when being translated to spaces when being written to the screen.

Expected is (would be nice to have) to recreate the TAB character when copying it back out (e.g. to the clipboard).

Test case

printf "A\tB\n"

While this yields A B" on a single line on screen, when copying it back out, it must becomeA\tB` again. I see pros and cons on both sides, so it might be interesting to have that feature configurable, such that users can decide what to do on tabs.

Configuration

Either via profile boolean flag or by extending the copy actions. But then the question would be how to distinguish this when using the vi normal mode.

Other Terminal's behaviour

didn't test much, but here we go:

Terminal	printf "A\tB\n"
gnome-terminal (vte)	retains TAB on copy
KDE konsole	TAB presented in spaces.

[cqexbesd]

Out of interest roxterm retains the tab. You also can't select part of the tab - if you drag over it you get all or none of it. With contour and the mouse I can get part of it if I start inside the tab, but only all of it, plus the next character if I start before the tab and move right. That's also weird behaviour.

OSX Terminal.app behaves like roxterm.

[christianparpart]

Oh interesting catch on Terminal.app. WRT roxterm, since it's libvte based, all TEs based on libvte should really behave the same on the lower end (that should include selection and TAB extraction). That makes sense.

We currently simply don't store the TAB information in the grid and directly move the cursor mod 8-style to the right. I didn't have the time to think of a proper way for implementing such a feature, sorry about this.

[Utkarsh-khambra]

I'm currently doing something similar to vte in #999