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 +-- ---==---(_)__ __ __ [EMAIL PROTECTED] |e| --==---/ / _ \/ // /\ \/ / http://schmorp.de/ --+ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE| |
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 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 +-- ---==---(_)__ __ __ [EMAIL PROTECTED] |e| --==---/ / _ \/ // /\ \/ / http://schmorp.de/ --+ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE| |
Bug#259828: tabs mangled to spaces when copying from xterm
On Tue, Jul 20, 2004 at 09:30:11AM +0200, Branden Robinson wrote: > On Fri, Jul 16, 2004 at 09:02:20PM -0400, Thomas Dickey wrote: > > On Fri, Jul 16, 2004 at 08:43:38PM -0400, Lee Revell wrote: > > > > > Just tried konsole and gnome terminal. Neither of them currently seem > > > to work this way, at least the versions in unstable don't. Even if > > > konsole supported this I could not use it, it took 10 seconds to start. > > > > I guess you have a fast machine. I just timed konsole's startup on my > > 2.66GHz box, and it took 22 seconds to get the window on the screen. > > Bwa ha ha ha ha. Bwa ha ha ha. > > You guys are *so* tickling my wicked schadenfreude gene. to be (a little fairer), once gnome-terminal is initialized, it can bring up additional windows in more/less real time. konsole's no improvement of course. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpLSSWetwLMS.pgp Description: PGP signature
Bug#259828: tabs mangled to spaces when copying from xterm
On Fri, Jul 16, 2004 at 09:02:20PM -0400, Thomas Dickey wrote: > On Fri, Jul 16, 2004 at 08:43:38PM -0400, Lee Revell wrote: > > > Just tried konsole and gnome terminal. Neither of them currently seem > > to work this way, at least the versions in unstable don't. Even if > > konsole supported this I could not use it, it took 10 seconds to start. > > I guess you have a fast machine. I just timed konsole's startup on my > 2.66GHz box, and it took 22 seconds to get the window on the screen. Bwa ha ha ha ha. Bwa ha ha ha. You guys are *so* tickling my wicked schadenfreude gene. Bwa ha ha ha ha. 505 [EMAIL PROTECTED]:~$ /usr/bin/time -v uxterm -e exit Command being timed: "uxterm -e exit" User time (seconds): 0.13 System time (seconds): 0.04 Percent of CPU this job got: 18% Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.90 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 0 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 1383 Minor (reclaiming a frame) page faults: 532 Voluntary context switches: 0 Involuntary context switches: 0 Swaps: 0 File system inputs: 0 File system outputs: 0 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 Bwa ha ha ha ha. processor : 0 cpu : 7455, altivec supported clock : 1249MHz revision: 3.3 (pvr 8001 0303) bogomips: 1248.46 processor : 1 cpu : 7455, altivec supported clock : 1249MHz revision: 3.3 (pvr 8001 0303) bogomips: 1248.46 total bogomips : 2496.92 machine : PowerMac3,6 motherboard : PowerMac3,6 MacRISC2 MacRISC Power Macintosh board revision : 0001 detected as : 129 (PowerMac G4 Windtunnel) pmac flags : L2 cache: 256K unified memory : 1024MB pmac-generation : NewWorld Under 1 second on a lowly Macintosh. Bwa ha ha ha ha. -- G. Branden Robinson|Fair use is irrelevant and Debian GNU/Linux |improper. [EMAIL PROTECTED] |-- Asst. U.S. Attorney Scott http://people.debian.org/~branden/ |Frewing, explaining the DMCA signature.asc Description: Digital signature
Bug#259828: tabs mangled to spaces when copying from xterm
On Fri, Jul 16, 2004 at 09:18:14PM -0400, Lee Revell wrote: > > > It seems like the mouse thing would be easy, if a click starts inside a > > > tab, that tab is part of the selection region. Same policy as clicking > > > on a space, you just treat tab as a big space. Then again I have never > > > hacked a terminal program so I can't really say. > > > > It's more complicated than that. xterm stores tabs expanded, and uses > > that in repainting (iirc, essentially the proposed patch set a bit at > > the beginning of the tab, so "all" that was left was to make the selection > > mechanism work). > > Ah, ok. Well, someone will fix this eventually. Maybe I will make a > feature request for gnome terminal. Thanks for the info. no problem (I may, on review of the patch I have, decide it's simpler to finish off than I would be thinking late on a Friday...) -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgp6gf0CoIgef.pgp Description: PGP signature
Bug#259828: tabs mangled to spaces when copying from xterm
On Fri, 2004-07-16 at 21:02, Thomas Dickey wrote: > On Fri, Jul 16, 2004 at 08:43:38PM -0400, Lee Revell wrote: > > > Just tried konsole and gnome terminal. Neither of them currently seem > > to work this way, at least the versions in unstable don't. Even if > > konsole supported this I could not use it, it took 10 seconds to start. > > I guess you have a fast machine. I just timed konsole's startup on my > 2.66GHz box, and it took 22 seconds to get the window on the screen. > No, actually, it's much slower than that, it probably took more like a minute to come up. I just said 10 seconds because I could not believe it had really taken that long, and figured I must not have been paying attention. Wow, has KDE gotten bloated. > > It seems like the mouse thing would be easy, if a click starts inside a > > tab, that tab is part of the selection region. Same policy as clicking > > on a space, you just treat tab as a big space. Then again I have never > > hacked a terminal program so I can't really say. > > It's more complicated than that. xterm stores tabs expanded, and uses > that in repainting (iirc, essentially the proposed patch set a bit at > the beginning of the tab, so "all" that was left was to make the selection > mechanism work). Ah, ok. Well, someone will fix this eventually. Maybe I will make a feature request for gnome terminal. Thanks for the info. Lee
Bug#259828: tabs mangled to spaces when copying from xterm
On Fri, Jul 16, 2004 at 08:43:38PM -0400, Lee Revell wrote: > Just tried konsole and gnome terminal. Neither of them currently seem > to work this way, at least the versions in unstable don't. Even if > konsole supported this I could not use it, it took 10 seconds to start. I guess you have a fast machine. I just timed konsole's startup on my 2.66GHz box, and it took 22 seconds to get the window on the screen. > It seems like the mouse thing would be easy, if a click starts inside a > tab, that tab is part of the selection region. Same policy as clicking > on a space, you just treat tab as a big space. Then again I have never > hacked a terminal program so I can't really say. It's more complicated than that. xterm stores tabs expanded, and uses that in repainting (iirc, essentially the proposed patch set a bit at the beginning of the tab, so "all" that was left was to make the selection mechanism work). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpnwgJNUr4fQ.pgp Description: PGP signature
Bug#259828: tabs mangled to spaces when copying from xterm
On Fri, 2004-07-16 at 20:08, Thomas Dickey wrote: > On Fri, Jul 16, 2004 at 07:52:06PM -0400, Lee Revell wrote: > > > Hmm, interesting, so it is fixable. I wonder if any other terminals do > > this already. It would definitely be a nice usability enhancement. > > Actually, I've read that gnome-terminal or konsole (don't recall which) does > allow selection of tabs, but that the implementation was poor (or in > my terms, the other 90% of the work wasn't done). > > The complaints I read stated that it was (a) hard to get the mouse to click > on the right place, (b) that selection across the right-margin didn't work > properly. Just tried konsole and gnome terminal. Neither of them currently seem to work this way, at least the versions in unstable don't. Even if konsole supported this I could not use it, it took 10 seconds to start. It seems like the mouse thing would be easy, if a click starts inside a tab, that tab is part of the selection region. Same policy as clicking on a space, you just treat tab as a big space. Then again I have never hacked a terminal program so I can't really say. Lee
Bug#259828: tabs mangled to spaces when copying from xterm
On Fri, 2004-07-16 at 19:45, Thomas Dickey wrote: > On Fri, Jul 16, 2004 at 07:40:06PM -0400, Lee Revell wrote: > > On Fri, 2004-07-16 at 19:30, Thomas Dickey wrote: > > > On Fri, Jul 16, 2004 at 07:15:33PM -0400, Lee Revell wrote: > > > > Sorry, I think this is important. It makes it impossible to copy and > > > > paste a diff into an email and have the patch apply cleanly. As a > > > > > > well, if it's blocking you, I suggest you submit a patch to fix it. > > > > Meh... don't have the bandwidth right now. Gnome terminal does the same > > thing, so I would imagine the fix is non-trivial. I will just have to > > go back to using mutt for email. > > I have an alpha-quality patch from someone for this in my backlog > (all I have to do is the other 90% of the work) > > but see the other stuff on Debian's bug-reporting system... Hmm, interesting, so it is fixable. I wonder if any other terminals do this already. It would definitely be a nice usability enhancement. Thanks again, Lee
Bug#259828: tabs mangled to spaces when copying from xterm
On Fri, Jul 16, 2004 at 07:52:06PM -0400, Lee Revell wrote: > Hmm, interesting, so it is fixable. I wonder if any other terminals do > this already. It would definitely be a nice usability enhancement. Actually, I've read that gnome-terminal or konsole (don't recall which) does allow selection of tabs, but that the implementation was poor (or in my terms, the other 90% of the work wasn't done). The complaints I read stated that it was (a) hard to get the mouse to click on the right place, (b) that selection across the right-margin didn't work properly. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpfgGk3mBQBx.pgp Description: PGP signature
Bug#259828: tabs mangled to spaces when copying from xterm
On Fri, 2004-07-16 at 19:30, Thomas Dickey wrote: > On Fri, Jul 16, 2004 at 07:15:33PM -0400, Lee Revell wrote: > > Sorry, I think this is important. It makes it impossible to copy and > > paste a diff into an email and have the patch apply cleanly. As a > > well, if it's blocking you, I suggest you submit a patch to fix it. Meh... don't have the bandwidth right now. Gnome terminal does the same thing, so I would imagine the fix is non-trivial. I will just have to go back to using mutt for email. Thanks, Lee
Bug#259828: tabs mangled to spaces when copying from xterm
On Fri, Jul 16, 2004 at 07:40:06PM -0400, Lee Revell wrote: > On Fri, 2004-07-16 at 19:30, Thomas Dickey wrote: > > On Fri, Jul 16, 2004 at 07:15:33PM -0400, Lee Revell wrote: > > > Sorry, I think this is important. It makes it impossible to copy and > > > paste a diff into an email and have the patch apply cleanly. As a > > > > well, if it's blocking you, I suggest you submit a patch to fix it. > > Meh... don't have the bandwidth right now. Gnome terminal does the same > thing, so I would imagine the fix is non-trivial. I will just have to > go back to using mutt for email. I have an alpha-quality patch from someone for this in my backlog (all I have to do is the other 90% of the work) but see the other stuff on Debian's bug-reporting system... -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgp9hLmRvFm27.pgp Description: PGP signature
Bug#259828: tabs mangled to spaces when copying from xterm
On Fri, 2004-07-16 at 18:34, Thomas Dickey wrote: > On Fri, Jul 16, 2004 at 11:40:08PM +0200, Lee Revell wrote: > > Package: xterm > > Version: 4.3.0.dfsg.1-6 > > Severity: important > ^ (disagree) > > > > > > xterm mangles tabs to spaces when copying/pasting with middle mouse > > button. > > It's a well-known limitation: xterm selects text which is on the screen. > Tab characters are (without any exceptions) translated to blanks. That's > modified somewhat by erasures and wrapping. > > (it would be nice to improve the behavior - but it's a minor issue). > Sorry, I think this is important. It makes it impossible to copy and paste a diff into an email and have the patch apply cleanly. As a result, some lists (like alsa-devel) request patches be sent as attachments. For a list like linux-kernel, where inline patches are preferred, there is no good alternative. The definition of an important bug (given by reportbug) is "a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone". How does the above fail to qualify? Lee
Bug#259828: tabs mangled to spaces when copying from xterm
On Fri, Jul 16, 2004 at 07:15:33PM -0400, Lee Revell wrote: > Sorry, I think this is important. It makes it impossible to copy and > paste a diff into an email and have the patch apply cleanly. As a well, if it's blocking you, I suggest you submit a patch to fix it. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpKPySjNgTAB.pgp Description: PGP signature
Bug#259828: tabs mangled to spaces when copying from xterm
On Fri, Jul 16, 2004 at 11:40:08PM +0200, Lee Revell wrote: > Package: xterm > Version: 4.3.0.dfsg.1-6 > Severity: important ^ (disagree) > > > xterm mangles tabs to spaces when copying/pasting with middle mouse > button. It's a well-known limitation: xterm selects text which is on the screen. Tab characters are (without any exceptions) translated to blanks. That's modified somewhat by erasures and wrapping. (it would be nice to improve the behavior - but it's a minor issue). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpTgEIyDxzid.pgp Description: PGP signature
Bug#259828: tabs mangled to spaces when copying from xterm
Package: xterm Version: 4.3.0.dfsg.1-6 Severity: important xterm mangles tabs to spaces when copying/pasting with middle mouse button. This can be easily reproduced by doing 'diff -u old_file new_file', then selecting the output and pasting into 'vim'. The tabs from the output have been converted to spaces. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.7 Locale: LANG=C, LC_CTYPE=C Versions of packages xterm depends on: ii libc6 2.3.2.ds1-13 GNU C Library: Shared libraries an ii libexpat1 1.95.6-8 XML parsing C library - runtime li ii libfontconfig12.2.3-1generic font configuration library ii libfreetype6 2.1.7-2.1 FreeType 2 font engine, shared lib ii libice6 4.3.0.dfsg.1-6 Inter-Client Exchange library ii libncurses5 5.4-4 Shared libraries for terminal hand ii libsm64.3.0.dfsg.1-6 X Window System Session Management ii libxaw7 4.3.0.dfsg.1-6 X Athena widget set library ii libxext6 4.3.0.dfsg.1-6 X Window System miscellaneous exte ii libxft2 2.1.2-6FreeType-based font drawing librar ii libxmu6 4.3.0.dfsg.1-6 X Window System miscellaneous util ii libxpm4 4.3.0.dfsg.1-6 X pixmap library ii libxrender1 0.8.3-7X Rendering Extension client libra ii libxt64.3.0.dfsg.1-6 X Toolkit Intrinsics ii xlibs 4.3.0.dfsg.1-6 X Window System client libraries m ii xlibs-data4.3.0.dfsg.1-6 X Window System client data -- no debconf information
