harp@cadillac.Berkeley.EDU (Christopher North-Keys) (07/22/90)
The KP_0/Insert lines are the trick to using the Keypad with a Sun type-4
keyboard --- without this trick, hitting the Insert/KP0 key will always do
an insert, regardless of shift being down.
The other translations allow the use of the PageUp/PageDown/Home/End keys.
Question:
Xterm has several obnoxious bugs(?) in the selection mechanism. Firstly, it
maps long wrapped lines incorrectly, so that using cut/paste will include a
spurious newline where the wrap was. Secondly, it maps tabs into spaces
erroneously. Thirdly, is stupidly maps a literal control-E into the
characters "^" and "E". All of these serious interfere with cut and paste.
Any solutions? I want to paste what I *entered*, you see, not what the damn
think takes it in mind to *display*. ("Much appreciated!" and all that :-)
!
! generic xterm characteristics
!
XTerm*name: xterm
XTerm*menuFont: *charter-medium-*-15-*
XTerm*reverseVideo: true
XTerm*reverseWrap: true
XTerm*title: xterm
XTerm*mouse: red
XTerm*cursorColor: green
XTerm*border: black
XTerm*scrollKey: true
XTerm*scrollBar: false
XTerm*c132: true
XTerm*fontMenu*font1*Label: Illegible
XTerm*fontMenu*font2*Label: Small
XTerm*fontMenu*font3*Label: Smooth
XTerm*fontMenu*font4*Label: Huge
XTerm*VT100*font1: nil2
XTerm*VT100*font2: 6x10
XTerm*VT100*font3: *smooth*bold*
XTerm*VT100*font4: *sony*24*
XTerm*VT100.Translations: #override \n\
~Shift <KeyPress> F23: set-scrollbar(toggle) \n\
~Shift <KeyPress> F27: scroll-back(100,page) \n\
~Shift <KeyPress> R13: scroll-forw(100,page) \n\
~Shift Meta <KeyPress> F29: scroll-back(1,page) \n\
~Shift Meta <KeyPress> F35: scroll-forw(1,page) \n\
~Shift <KeyPress> F29: scroll-back(1,line) \n\
~Shift <KeyPress> F35: scroll-forw(1,line) \n\
Shift <KeyPress> KP_0: string("0") \n\
~Shift <KeyPress> Insert: insert-selection(PRIMARY, CUT_BUFFER0) \n
!
______________________________________________________________________________
Christopher North-Keys Assoc. Systems Analyst
Group Talisman Harp[@Mcc.Com]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~mouse@SHAMASH.MCRCIM.MCGILL.EDU (der Mouse) (07/22/90)
> Xterm has several obnoxious bugs(?) in the selection mechanism. > Firstly, it maps long wrapped lines incorrectly, so that using > cut/paste will include a spurious newline where the wrap was. > Secondly, it maps tabs into spaces erroneously. Thirdly, is stupidly > maps a literal control-E into the characters "^" and "E". The first two of those could be fixed, though it would probably be a bit of work. The last cannot. > I want to paste what I *entered*, you see, not what the damn think > takes it in mind to *display*. There are three things here: 1) what you type 2) what gets printed to the window 3) what the window displays Currently it's cutting (3). The best you can do is to come close to (2), which will fix the first two of your gripes but not the third. (Why can't you cut (1)? Imagine: you type "ls", change your mind, type three deletes, and type "pwd". You now cut this "pwd". Do you really expect to get l s DEL DEL DEL p w d? Suppose you start vi and immediately :q out of it. You cut the whole screen. Do you expect to get v i CR : q?) Even cutting (2) is very difficult. The primary problem is handling cuts correctly when the display has been built up by cursor-addressing all over the place, as is done by (for example) emacs. (For the sake of argument, ignore emacs variants which run in their own window, like epoch. I picked emacs as an example; rogue would do equally well.) For example, suppose we print f o o TAB b a r which generates (on the display) f o o SPACE SPACE SPACE SPACE SPACE b a r Now, if this is cut, you want to get the former. But now suppose a cursor-address is done and an x is written over the middle space. The display now shows f o o SPACE SPACE x SPACE SPACE b a r If you now cut this, do you expect to get any TABs? If so, where? And above all, why? Completely correct handling of cuts is dangerously close to "do what I mean"; it's nearly impossible to state precisely what cutting should do in unclear cases without resulting in an algorithm that badly mishandles some clear cases. I've been wrestling with these questions as they relate to my terminal emulator, but haven't found any answers yet...I'd like to hear anyone's thoughts on the matter. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
mouse@SHAMASH.MCRCIM.MCGILL.EDU (der Mouse) (07/23/90)
> We add wrapped-newlines, control-carats, and space-in-tab codes to > the existing display codes [...]. The wrapped-newlines and space-in-tab are reasonable; the control-^ sounds reasonable but isn't. The reason it isn't is that it's printed to the pty as hat-plus-letter, unlike the others. That is, xterm can't tell whether that ^-followed-by-E is supposed to be a control-E or not. A tab is received by xterm as a tab, and xterm chooses to display it as some number of spaces; wraps are generated internally anyway. But a ^E representing control-E will be received by xterm as ^-plus-E, not as a control-E character, hence the problem. There's another problem with tabs: they are generally not destructive. For example, the "foo^^^^^bar"->"foo x bar" example could just as well be sent to xterm as " x\rfoo\tbar" (to use the C conventions) instead of the "foo\tbar\r\33[5Cx" we have been assuming. (Or something like that; the details are irrelevant.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
guy@auspex.auspex.com (Guy Harris) (08/05/90)
>Now, if this is cut, you want to get the former. But now suppose a >cursor-address is done and an x is written over the middle space. The >display now shows > > f o o SPACE SPACE x SPACE SPACE b a r > >If you now cut this, do you expect to get any TABs? I might. > If so, where? In place of the second two SPACEs. > And above all, why? Solely in order to get me a TAB in the case where there was only a TAB sent to the "terminal". Not giving any TABs would probably also be acceptable; the main reason I'd want tabs would be if I were cutting text that *hadn't* been overwritten, although I might want to cut'n'paste from an editor screen (but in that case I should be running an editor that runs directly under X, so I'm cutting from the *editor's* buffer rather than the terminal emulator's buffer; after all, many editor won't literally throw tabs onto the screen if the line contains tabs, as it may be more efficient for them to do something else - we would *definitely* be talking DWIM in that case). However: >Completely correct handling of cuts is dangerously close to "do what I >mean"; it's nearly impossible to state precisely what cutting should do >in unclear cases without resulting in an algorithm that badly >mishandles some clear cases. is probably applicable here. I could certainly live with getting SPACEs (and have done so for several years, with e.g. "shelltool"). When passing stuff through a program's output code (especially an editor's screen-display code), a tty driver, and a terminal emulator, there are plenty of places where information can get irretrievably lost; given that, it may not be possible to reconstruct that information in a fashion acceptable to everybody.