Bug#259828: tabs mangled to spaces when copying from xterm - ideas on semantics
I thought about implementing this in rxvt-unicode: tabs could be represented
trivially in rxvt-unicode's data structure. However, there are semantic
Tabs are not characters, but cursor movements. As such, there is no good way
to represent them as tab characters, just as "cursor up" or "goto 5,6" will
not be represented in the selection text.
Here are some problematic examples (case 1)
This might print:
Now, what should be in the selection when this is selected? hi\tho?
If you think so, then this example is more problematic:
This might output (case 2)
Where is the tab now, when this is selected?
I have thought about usign a heuristic. There are, however, many ways to do
this. For example:
a) check wether we tab over spaces, when yes, make it a real tab,
otherwise leave it as spaces. Neither case 1 nor case 2 will have a tab
b) replace spaces (if any) before the tab position by a tab. This will
create a tab in case 1, but no tab in case 2.
b2) replace spaces (if more than 2)... this will use a space when there is
only a single space.
c) something else...?
So before implementing this, one should decide (and think) about the
semantics that this should have, especially when more terminals want to
do this, so that they can be consistent (and i want rxvt-unicode to be
consistent to xterm in this respect :)
The choice of a |
-----==- _GNU_ |
----==-- _ generation Marc Lehmann +--
---==---(_)__ __ ____ __ email@example.com |e|
--==---/ / _ \/ // /\ \/ / http://schmorp.de/ --+
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE |