Path: utzoo!attcan!uunet!cs.utexas.edu!wuarchive!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!phil From: phil@ux1.cso.uiuc.edu Newsgroups: comp.windows.x Subject: Re: xterm behaviour Message-ID: <22700023@ux1.cso.uiuc.edu> Date: 14 Oct 90 23:28:00 GMT References: <189@honold.UUCP> Lines: 69 Nf-ID: #R:honold.UUCP:189:ux1.cso.uiuc.edu:22700023:000:3183 Nf-From: ux1.cso.uiuc.edu!phil Oct 14 18:28:00 1990 > While pressing down the left mouse button, you can select a piece of text. > Now, assume that you've selected three lines inside xterm. Actually, > this selection is a very long "one-line" command just entered by you. > When you press the middle button to "paste" your selection in another xterm > or vi, it will insert three lines and NOT one very long line. To say it > with other words: xterm does not know when you've typed in a . It simply > puts a EOL after each "visual" line-break, not knowing when it has done > a wraparound with your input. It also pastes all whitespace as blanks, regardless of how that white space got to be there. Of course doing this all correctly is very very tricky. A tab might mean a very different kind of thing than it visually appears to be when cut, depending the context in which it is pasted. The xterm program would have to keep a record of the ascii stream used to create the entire screen image, including the entire scroll buffer, in order to do this correctly. That requires even more memory and processor time. If such a feature is added, an option should at least allow turning it off if it is not the default. If that capability exists, then it would also be possible to build the image of the screen in the new context when the window is resized. In other words, what once was wrapped might not be, or might be in a different place, when the window is enlarged. I'd also like an option, perhaps called "-tiny" that puts the newly opened window in the "tiny" font, yet allows selecting default to bring it back out. > Another minor bug is, that if there are blanks at the end of your > text selection, xterm does not copy these blanks into the selection buffer, > and consequently, will not paste it into any application. Probably an artifact of the programmer's dilemma on dealing with tabbed white space. But maybe not, since it does NOT behave this way on leading white space. > Has anybody else noticed this logically wrong behaviour of xterm? I don't know that it is logically wrong. If you had the ability to cut out the exact string that created the text, consider a program, such as the worm game, that effectively creates the screen image entirely by random address. Perhaps a simpler example: Suppose I output the stream: ^M^Jthis is a test string^M^Ia fake^M^J What you would see on the screen is this is a fake string So when you cut out this line and paste it in somewhere else, what is the DEFINITION of what you are doing: 1. Taking the string you see and cutting it 2. Taking the complete stream that resulted in what you see and cutting it What if you only paste out the "ke str" part? Then what? My point is that doing OTHER THAN visual cut and paste requires defining what you are doing in a way that is quite probably *VERY* difficult to do. > I appreciate any comments or solutions. I wish I had solutions. I expect them to be difficult and costly to implement just because the definition of what is going on would be so vague. --Phil Howard, KA9WGN-- | Individual CHOICE is fundamental to a free society | no matter what the particular issue is all about.