lichtin@olsen.UUCP (Martin Lichtin) (10/05/90)
My only complaints about X are that wipe in xterm doesn't know about wrap- around (really annoying when you type long command lines, since that's when you will probably need to wipe) and that word-mode wipe will let you high- light trailing blanks, but it won't stuff them. Are there any solutions to these problems? P.S.: "shelltool" under sunview knows how to do it. Thank you.
mouse@LARRY.MCRCIM.MCGILL.EDU (10/06/90)
> My only complaints about X are that wipe in xterm doesn't know about > wrap-around (really annoying when you type long command lines, since > that's when you will probably need to wipe) and that word-mode wipe > will let you high-light trailing blanks, but it won't stuff them. > Are there any solutions to these problems? "wipe" is not a feature of xterm per se; the tty driver simply prints backspaces and spaces to erase things. The problem is that xterm by default has forward wrap enabled and backward wrap disabled. IMO this is a bug (I maintain that they should either both wrap or neither wrap). It is possible to turn on backward wrap or turn off forward wrap. There is a menu available on control-mousebutton2 which allows this; I understand it can also be done with resources and/or command-line options but I don't know how. (I basically never use xterm.) It's not clear what your second problem is, and as it seems to involve cut-and-paste in xterm, I probably couldn't help with it in any case. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
sarima@tdatirv.UUCP (Stanley Friesen) (10/09/90)
In article <189@honold.UUCP> lichtin@olsen.UUCP (Martin Lichtin) writes: >My only complaints about X are that wipe in xterm doesn't know about wrap- >around ... >Are there any solutions to these problems? > >P.S.: "shelltool" under sunview knows how to do it. In that case 'shelltool' under X also knows about wraparound. Yes, that's right, 'shelltool' exists under X! So do most of the other Sunview tools from Sun. They are provided standard with Sun's implementation of X, called OpenWindows. [I too find xterm rather primitive compared to shelltool]. P.S. OpenWindows also allows you to run SunView applications directly. [with some annoying disadvantages]. -- --------------- uunet!tdatirv!sarima (Stanley Friesen)
johndoe@inmet.UUCP (johndoe ) (10/11/90)
In article <14@tdatirv.UUCP> sarima@tdatirv.UUCP (Stanley Friesen) writes: >In article <189@honold.UUCP> lichtin@olsen.UUCP (Martin Lichtin) writes: >>My only complaints about X are that wipe in xterm doesn't know about wrap- >>around ... >>Are there any solutions to these problems? >> >>P.S.: "shelltool" under sunview knows how to do it. > >In that case 'shelltool' under X also knows about wraparound. Yes, that's >right, 'shelltool' exists under X! So do most of the other Sunview tools >from Sun. They are provided standard with Sun's implementation of X, called >OpenWindows. [I too find xterm rather primitive compared to shelltool]. > >P.S. OpenWindows also allows you to run SunView applications directly. >[with some annoying disadvantages]. >-- >--------------- >uunet!tdatirv!sarima (Stanley Friesen) xterm does wraparound for me just fine. and i don't know what other features of xterm you consider primitive in comparison to shelltool: you can copy and past with ease between xterms. you can use scroll bars, define alternate fonts, define colors (if your terminal is color) that vary for the background, foreground, edgespace, and cursor. you can specify the startup space and the terminal size, and if you resize your xterm, it will automatically set your terminal row and column characteristics for you, even if you happen to be running emacs in the xterm window. but i have to admit, when i would run my full .profile (using ksh), i found that as i overrode the terminal type and stty defaults set at the startup of the xterm, i found that wrap and size functions didn't work either. i discovered this quite by accident. when i would rlogin from the vaxstation i was using to the sun4 i wanted to start the xterm on, and then 'xterm &', i found that my wraps weren't working, and that my emacs terminal wasn't hiding my screen text but overriding it. then, i started using rsh to the sun4, specifying the xterm and arguments as the rsh command to run. this had the annoying effect of not executing my .profile, but it set my terminal up in the proper modes for wrap, usw. it was then very easy to start up an alternate .profile with the terminal characteristics stripped out. -johndoe@inmet.inmet.com )kirk beitz(
lichtin@olsen.UUCP (Martin Lichtin) (10/13/90)
I notice that my question about <"wipe" in xterm> has been misunderstood. My problem is the "copy-and-paste" mechanism of xterm. 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 <CR>. It simply puts a EOL after each "visual" line-break, not knowing when it has done a wraparound with your input. 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. Has anybody else noticed this logically wrong behaviour of xterm? I appreciate any comments or solutions. Thank you.
phil@ux1.cso.uiuc.edu (10/15/90)
> 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 <CR>. 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 <phil@ux1.cso.uiuc.edu> | no matter what the particular issue is all about.