GNOME Bugzilla – Bug 528077
VT100 emulation issues
Last modified: 2018-03-27 17:45:49 UTC
Please describe the problem: Version 0.12 worked fine. Version 0.16 (and possibly others between) broke VT-100 emulation regarding curson positioning and inverse video fields. Symptoms include: failure to properly position inverse fields, improper handling of scrolled areas where inverse fields appear above or below proper locations, improper substitution of characters (===== where ____) should be. Steps to reproduce: 1. A good test program is the veneralbe 'tinyfugue' mu* client. (Note: tinyfugue works perfectly for many years with a real VT-100 compatible terminal, other properly functioning VT emulators, and at least VTE 0.12.) 2. Enable 'visual' mode, status line, snd clock. 3. Enable 'more on'. 3. Interactively receive text from a server which exceeds the number of lines in the upper display area. This displays an inverse MORE on the status line, along with the number of lines which are pending. Pressing TAB scrolls the upper window, decrementing the number of lines shown with MORE until all have been displayed at which time, the area of the status line reverts to ______. 4. Run the 'pine' or 'alpine' text-based e-mail client. Actual results: The tinyfugue status line which appears between upper (server-sent text) and lower (user text entry) areas is easily corrupted, especially when the "MORE" inverse field is used to indicate unseen text is available. Upeon finishing display of all pending lines, the MORE display is not cleared and remains showing an incorrect number of lines. At times, the atatus line is replaced with ===== instead of ______ characters. At times MORE will display above the line where it should appear. Likewise, inversed aread of the various menues and hilighted areas is garbaged and improperly placed. Expected results: Proper placement and text within inversed areas, Proper placement of cursor-positioned fields. Proper display of characters. Does this happen every time? Yes. Obxerved on multiple machines using later VTE versions, including Ubunto, Xubunto, slackware, and even the OLPC laptop. I've not seen a recent linux distor with VTE that works properly. Other information: I've noticed that once a screen is painted improperly sometimes a ctl-l to refresh the screen will result in a proper display for that particular screen for (as long as it remains static). I noted a very old bug report about VTE not passing VT emulation tests in early versions. It appeaers issues have crept back into the later versions.
This problem continues in most major distros using VTE, including Ubuntu, OLPC, Fedora and others. It is most notable when there is incoming/scrolling text while cursor is being repositioned to secondary windows or status lines. It is fairly sympomatic of older VT terminals which lost part of the escape sequences at higher baud rates they were unable to keep up with. At any rate, VTE worked once, and remains broken.
Saying "VT-100 emulation regarding curson positioning and inverse video fields" is not specific enough. Please give detailed descriptions of what vte does, what it should do and provide a clear explanation on how to reproduce the behaviour. "Interactively receive text from a server which exceeds the number of lines in the upper display area" assumes familiarity with what a "mu* client" is (I, for one, have no idea...), on how to connect to a server, and etc. What do you mean by "Proper placement and text within inversed areas, Proper placement of cursor-positioned fields. Proper display of characters." as expected results? As given, what you wrote is as helpful as saying that you expect vte to work properly. In lots of cases, fixing the emulation is a very simple matter *once* the developers know what they are supposed to fix...
Created attachment 128665 [details] Screenshot-0 Tinyfugue start screen. The Ubunto distribution defaults to the 'visual on' mode which creates a split screen, top for incoming text, bottom for composing outgoing text and issuing commands. Some compiled versions would need to have the command '/visual on' issued to get this modes. Both the VTE and Xterm screens appear similar at this point. Some resolution has been lost in cropping the screenshot image down to relevant parts.
Created attachment 128666 [details] Screenshot-1 The Ubuntu version defaults to '/more off', so we issue the command '/more on' to enable the incoming text to be paged rather than free-scrolling. For numbers of lines of text exceeding the upper screen limit, paging halts the display and buffers the remaining lines to allow time to read. Pressing 'tab' will scroll to the next screen of text until all have been seen. There is a status line update indicatating that 'more' text remains along with a number to show how many lines are pending. Note here that VTE has inserted a spurious black cursor after '/more on'. This should not be present in a proper display as seen in the Xterm window.
It's difficult to describe since the mis-behavior is dependent on the application being run in the terminal, and exact conditions for some are hard to duplicate (amount of incoming text, previous state of the displayed page, etc.). Maybe pictures will help. I've put in some screenshots of highly repeatable conditions. As for a mu* client, it's a glorified telnet tailored to connecting to any of the thousands of text-based mud, muck, mush online text-based games. Tinyfugue is one of the oldest and widely used since it compiles and runs on virtually everything. It is described and source is available from a link here: <http://en.wikipedia.org/wiki/TinyFugue>. The latest version of Tinyfugue is available in the Ubuntu repository, and can be had by doing 'sudo apt-get install tf5'. I used the stock Ubuntu to generate the example screenshots, but the symptoms are exactly the same on any machine running later VTE versions. Version 0.12 worked fine, 0.16 and after do not. I haven't tried ones between 0.12. and 0.16, so not sure just which release broke things. In the screenshots, I have placed a VTE terminal next to a plain X-term running the exact same Tinyfugue application to demonstrate some ways in which VTE fails. This can be duplicated dynamically by simply running the program yourself and using the same commands as in the shots. Each one has a comment which describes what was done, and the result.
Created attachment 128667 [details] Screenshot-2 Here we have logged into an online world at the server and port listed on the command line. Note that the spurious cursor block remains on the VTE screen.
Created attachment 128668 [details] Screenshot-3 Here we have logged into the world using the 'guest' account with the command string 'connect guest guest'. This shows how the '/more on' paging works, showing the paused display with buffered lines pending. The VTE window shows 10 lines because the second login in the Xterm window resulted in a message to the first as both 'guest' characters are in the same virtual room.
Created attachment 128669 [details] Screenshot-4 Both screens show the result of pressing 'tab' to advance the display to see the next page of lines. Since there were only 9 or 10 pending, they fit on the screen with no more pending. Note that the VTE window did not properly re-write the status line, and still shows 10 lines remaining which don't exist. The X-term window properly updated the status to remove the indication of pending lines.
Created attachment 128671 [details] Screenshot-4 Both screens show the result of pressing 'tab' to advance the display to see the next page of lines. Since there were only 9 or 10 pending, they fit on the screen with no more pending. Note that the VTE window did not properly re-write the status line, and still shows 10 lines remaining which don't exist. The X-term window properly updated the status to remove the indication of pending lines.
Created attachment 128672 [details] Screenshot-4 Both screens show the result of pressing 'tab' to advance the display to see the next page of lines. Since there were only 9 or 10 pending, they fit on the screen with no more pending. Note that the VTE window did not properly re-write the status line, and still shows 10 lines remaining which don't exist. The X-term window properly updated the status to remove the indication of pending lines.
Created attachment 128673 [details] Screenshot-5 Here we see the result of issuing a help command requesting an alphabetical list of all the server commands available. Since this is a long list, there are 69 lines pending.
Created attachment 128675 [details] Screenshot-6 Here we see the result of pressing tab to get the next page of text. VTE has failed to rewrite the status line properly, leaving 69 as in the previous screen, while Xterm properly updated the line. All subsequent 'tabs' properly decrement the number in the status line in Xterm, while VTE is stuck with 69.
Created attachment 128676 [details] Screenshot-7 Here is the last page of text which had been buffered by the pager. Note that VTE *still* shows 69 lines while Xterm properly shows none.
Created attachment 128677 [details] Screenshot-8 Here we entered 'ctl-l' in the VTE window to refresh the display from the previous screenshot. VTE now correctly repaints the status line with the proper display.
Created attachment 128678 [details] Screenshot-9 This clip shows another typical way VTE wrongly paints the status line. In this case, there should be a 'MORE 14' displayed, but VTE has just displayed a bolded line overscore in the field.
I apologize for the out of order posts and duplicates above. The proper order should be #5, #3, #4, #6 and so on. Likewise, there should only be one posting referencing Screenshot-4, so #9 and #10 are dupes. Bugzilla/the net was was hanging on some posting attempts, but apparently the submissions went though. I don't see any way to delete the superflous ones. [QUOTE] What do you mean by "Proper placement and text within inversed areas, Proper placement of cursor-positioned fields. Proper display of characters." as expected results? As given, what you wrote is as helpful as saying that you expect vte to work properly. [/QUOTE] What I mean is that if the word ' Giraffe ' were in an inverse field with the field extending one character space before and after as shown, I would not expect to see 'Giraffe ' or Gi'raffe ' where the text and the inverted video parts are not correctly aligned or of incorrect length. Likewise, if there is a vertical list where the inverse video marks the cursor, like: 1 '2' <---- '' marks inverted, selected field 3 I would not expect the display to invert 1 or 3 if the 'actual cursor' is selecting 2. I would also not expect something like: 1 2 ' ' <--- a mispositioned inverse block 3 or 1 '2' 3 <--- where a field isn't properly positioned I've seen variations of this sort of thing in a number of applications. In particular, I have been burned in the 'pine' e-mail client where an inverse video line marks the selected message in the list of e-mail messages. The mis-positioning of the highlight/inverse cursor one line above where it should have been caused inadvertent deletion of the wrong message. I do not have ready examples or screenshots since I have reverted the machines I use regularly to VTE version 0.12, and I avoid using VTE terminals on those which I can't. When the misbehavior is obvious, it's merely annoying; but when it's not, it's dangerous.
Created attachment 128690 [details] Screenshot-10 Another oddity - This shows the status line incorrectly indicating 22 lines remaining when there are indeed just 2. This is the 'before' shot.
Created attachment 128691 [details] Screenshot-11 This is the exact same page as in Screenshot-10. No keys were pressed at all. However, the mouse was used to highlight the last few lines of the VTE terminal screen as if load the clipboard for a copy/paste of the hilighted text. As soon as the expanding mouse-hilighted area touched the status line, it was redrawn to properly indicate 2 lines pending. The paste buffer also contained the correct text including 'MORE 2'.
Please also get a script of the terminal output, plus the timing information, using the script command (see its manual page), from running the steps necessary to reproduce the problem.
(In reply to comment #19) > Please also get a script of the terminal output, plus the timing information, > using the script command (see its manual page), from running the steps > necessary to reproduce the problem. It's attached. I performed the same basic steps to create the first series of screenshots. At two points where the status line was not updated properly, I typed ctl-l to force a refresh. The first was just after the completed login, and the second was at the end of the long 'help alpha' listing. In that listing, I only pressed 'tab' to advance, and did not force any repaints.
Created attachment 128694 [details] Script output Script output capture using commands like those used to create the screenshots.
Created attachment 128695 [details] Script output with timing run This script output goes with the timing file.
Created attachment 128696 [details] Script timing output Timing file for preceding script.
Created attachment 128701 [details] Script output 2 After playing with script and playback some, I created this one which is a bit cleaner (I didn't exit the shell back far enough with the first one, so it has unrelated garbage.) I also paused longer between entered commands so intermediate results can be seen easier. I also tried playing it back with VTE 0.12, and (as expected) it works as expected with that.
Created attachment 128702 [details] Script timing 2 This is the timing file for Script output 2.
Created attachment 129986 [details] Screenshot-10 - VTTEST comparison This is a shot of a VT-compatibilty test using vttest, which is available from <http://linux.softpedia.com/progDownload/vttest-Download-22017.html>. The test is one of the 'Test of screen features' set. Note that the xterm screen alongside shows how the VTE rendering of the test is incorrect.
Closing this bug now; there've been many many changes since this was opened and it's unclear if any issues still apply. If you find a problem with either vttest or any other programme using vte git master please report new bug(s, one per issue). (Make sure you use vttest from https://gitlab.gnome.org/chpe/vttest ).