Re: ugly printing (stepper) fix

[William.Lott@CS.CMU.EDU]

Todd.Kaufmann@PARIS.MT.CS.CMU.EDU writes:
> The printing from the stepper is much uglier than it needs to be.  The
> stepper is doing something wierd.  Is there another xp:*print-dispatch*
> especially set to print things like this?
> 
...
> Well, I decided to look at it, and found the following:
> the charpos isn't getting reset.
...
> The problem seems to be that the input is out of sync with the output;
> ie, if I hit return, then charpos really should go to zero.  I only see
> this being set in output routines, none of the input functions.

This is exactly what is going wrong.  It is only set in the output
functions because normally, it is just a function of what has been
output.  The terminal is strange in that input automatically gets
echoed to the output and can therefore change the current character
position.

Setting the charpos slot in the input routines will not work, because
that is a different stream (sys:*stdout* vs. sys:*stdin*).

We can't even special case stdin/stdout because you can redirect them
independently from the shell.  We can't check to see if they are a tty
or a pipe and do something different, because you could do something
strange like redirect output to a different tty.

What you really need is an IOCTL that will tell you the character
position.  But I doubt we could get the MACH people to add it.

One might argue that if we can't get evey case correct, the case we
choose to do correctly should be the most common case (i.e. no
redirection).  I'll probably change something so that the normal cases
work and the weird cases act weird, but any changes I make will only
appear in the new system, as we are no longer developing the old RT
system.

Note that this is not a problem when using slaves under Hemlock,
because they do not use regular file-descriptor streams.

> Where is *terminal-line-mode* used?  I didn't see it in *stream.lisp.
> I'm guessing step-get-char had it once; now doesn't.

To the best of my knowledge, it is an artifact from earlier versions.

-William Lott
CMU Common Lisp Group