Bug#259828: tabs mangled to spaces when copying from xterm - ideas on semantics
Hi, I just submitted additional info on your bug report #259828, but forgot
to CC: you. The problem why this is non-trivial is that tabs are not replaced
by spaces (as TD said), but that tabs are cursor movements, which cnanot be
represented as tabs. See below:
-----------------------------------------------------------------------------
I thought about implementing this in rxvt-unicode: tabs could be represented
trivially in rxvt-unicode's data structure. However, there are semantic
problems:
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)
echo $'hi\r\tho'
This might print:
hi ho
Now, what should be in the selection when this is selected? hi\tho?
If you think so, then this example is more problematic:
echo $'01234567\r\t89'
This might output (case 2)
0123456789
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
than.
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 +--
---==---(_)__ __ ____ __ pcg@goof.com |e|
--==---/ / _ \/ // /\ \/ / http://schmorp.de/ --+
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE |
|
Reply to: