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
