DEC VT100/220 line wrapping semantics sought

[allison]

On 01/01/2017 02:39 PM, Mattias Engdegård wrote:
> Would someone with a real DEC VT terminal be so kind and help settle, once and for all, the question about how they behave with respect to line-wrapping, exactly? It is something that isn't covered by any standard, nor by any of DEC's manuals, and there is a scarcity of information online that is not vague repetition of folklore.

The terminals SRM did cover this from the VT220 on.  The transition from
VT100 and related add on versions to the
monolythic VT220 required setting standards for all terminals as up to
that point it was NOT consistent within VT100
models or prior to VT100 (VT05 and VT52).
> There are emulators, of course, but these do not agree with one another to the point that they can be trusted, and are probably just copying each other in any case. It seems that some ground truth would be welcome, for the benefit of both application and emulator writers.
>
> First, the problem: A VT100, when in "auto-wrap" mode, will wrap text from one line to the next in a peculiar way, sometimes called "soft-wrap" or "the VT100 glitch". When the terminal receives a printable character with the cursor in the last column, the character is put at that location but the cursor remains in place. Instead, the terminal enters a pending wrap state, which causes the cursor to wrap before next printable character is displayed. This behaviour is widely known.
>
> What isn't widely known are the finer points:
>
> * What control codes will cancel the wrap state?
> * What cursor position is reported in the wrap state?
> * Do any operations behave differently in the wrap state?
> * Is the wrap state saved/restored by the save/restore cursor codes?
>
> and so on. Every emulator programmer seems to have a different answer to these questions.

All of that is due to either not understanding weather the terminal
setup for vt100 is set to wrap or
the ansi controls were setting it to wrap.  Further the various flavors
of VT10X did not always agree.
plus over time there were several firmware changes to correct errors
that may or may not have
had odd effects.

General form for wrap was the characters would pole at the end with the
cursor set there.
If line-wrap were enabled the excess characters for that line would wrap
to the next line
as they exceed the line length.  This was generally true for 80 char
lines but not always for
132 char lines and double width (40 char) lines where those were
implementation (model)
dependent.

> If you have a VT100, VT220 or later model (compatibles like Wyse are also of interest) and have a spare moment, I'd be most grateful if you would download and run

Be very wary as the setup to the test must be specific.  Also the exact
model must be known.

Much of the behaviors depend on:
 
preset line length (characters per line) (setups screen and control codes.)
Preset screen (lines) (or status line enabled) (setup screen)
Line wrap enabled (setup screen)
Newline/no newline (setup screen)
Soft scroll or jump scroll (setup screen)
prior ANSI (DEC control codes)
VT52, VT100, or VT220 mode

So to validate the action that results one must know what the user setup
screen has preset
and if any other ansi/dec/vt2 control codes have been previously sent. 
Also if the cursor was first line
or last tine of in the mid screen area.  IF cursor addressing is in use
the cursor position for each case.

> https://raw.githubusercontent.com/mattiase/wraptest/master/wraptest.c
>
> in that terminal, and send me the resulting output. (Redirect stdout to save the report.)
> The test program is not comprehensive but would give us a good idea of the rules.
>
> Current results, right now only from various emulators, are found in
>
> https://raw.githubusercontent.com/mattiase/wraptest/master/results.txt
>
Most PC based emulators get it wrong.  Most really get it wrong on
keyboard to terminal key
alignment.  They rarely have the setup screen actions for the keyboard
mapping.

Even the terminals group at DEC and the terminals and printers test
group would tend to argue
what was the intended action vs what it really did, especially during
development.  After the
Terminals SRM was developed there would be exceptions galore (for
example DECMate
terminal behavior and the various PCs (Pro, Rainbow, Vaxmate) in
terminal emulation mode.

FYI when using terminal emulation I defer to VT52 as that is both the
simplest to get right
and emulate however most keyboard on PCs still have it seriously wrong. 
Plan B is use a real
terminal such as VT100, VT125, VT220, VT320 or Vt340, or the VT1200 as I
have those.
The most reachable is the VT320 (on my CP/M system) and VT340
(PDP-11/73).   They get
used as they are smaller than the VT100s I have.

Allison