Mark remarks:

> This is Day One of full-time use of my new Windows XP machine using QCTerm
as
>  my terminal emulator.  Most of my limited QCTerm use so far has been with
> Linux and vi.
>
>  Many Linux programs assume that your terminal has tab stops set every 8
>  characters, so I had to configure QCTerm to define the expected tab stops.
>
>  One issue already on Wirt's to-do list is that the Linux telnet server
reads
>  the terminal type as "network" instead of the value "hp" that I've
> configured
>  into QCTerm.  As a workaround, I've modified my .bash_profile to manually
>  export TERM=hp.

The two problems may be related. Although I know nothing of Linux (we did
however order a Dell server with Red Hat's Linux 7.2 just a few days ago and
we should all be gurus by the end of the week here), the right and proper way
for such things to work is: (i) the O/S and the terminal should negotiate the
form of terminal emulation, and (ii) once that's been decided, the O/S sets
the NVT client up the way it needs it, which is this case, apparently
requires setting the tabs every 8 positions, transmitting the
terminal-appropriate escape sequences to terminal. If Linux is doing that
now, but using the wrong terminal type's escape sequences, or deciding or not
to transmit them before it knows the terminal type, then the tabs wouldn't be
getting set.

Of course, all of this speculation. This is merely how it should be done. But
I am completely wary that we're entering a zone of "good design" and I am
expecting the worst.

Nevertheless, terminal type negotiation (option 24) is a currently
unsupported telnet option in QCTerm. The HP3000 simply doesn't perform that
negotiation because it demands and expects an HP terminal as its client, thus
terminal type negotiation was not only very low on our priority list for
QCTerm, we didn't even have anything to practice against.

But as I say, now that we're all going to be Linux gurus, we'll put it into
QCTerm very soon.


>
>  Another issue that I just discovered is that screen drawing isn't working
>  correctly when doing vi editing.  You can illustrate the problemm by
> creating a
>  new file:
>
>  [mark@odo mark]$ vi qcterm.txt
>
>  Then enter "i" and type a lengthy line, followed by ESC to get out of data
> mode:
>
>  this is a test of the qcterm terminal emulator
>
>  Then backspace to the beginning of this line, enter "i" again, then hit
the
> Tab
>  key to insert a tab, then ESC to get out of data mode:
>
>  this is        this is a test of the qcterm terminal emulator
>
>  But this is incorrect; the leading "this is " does not really exist.  If
you
>  ask vi to redraw the screen by entering CTRL-L, you see the correct line:
>
>           this is a test of the qcterm terminal emulator

I very much appreciate a complete key-by-key description of how to get to the
problem, as Mark did here. Whatever the problem is with QCTerm, I'm sure that
it's very small and we're always very pleased to fix these kinds of things. I
hate errors.

Working with UNIX is undoubtedly going to uncover a few more pecadillos that
we never exercised or saw with MPE, but we are very interested in finding
them and exorcising them.

Wirt Atmar

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *