Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!usc!snorkelwacker!bloom-beacon!SHAMASH.MCRCIM.MCGILL.EDU!mouse
From: mouse@SHAMASH.MCRCIM.MCGILL.EDU (der Mouse)
Newsgroups: comp.windows.x
Subject: Re:  X11R4 xterm twists: PageUp/PageDown, Sun4 Numeric/Keypad, etc.
Message-ID: <9007221152.AA00736@shamash.McRCIM.McGill.EDU>
Date: 22 Jul 90 11:52:11 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 63

> 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