Community
Participate
Working Groups
Created attachment 272318 [details] Installation details > configuration Steps to reproduce: (1) Open a terminal view (2) open nano editor by typing nano (3) Insert a few lines, e.g. line 1 line 2 line 3 (4) move cursor to the beginning of line 2 (5) press CTRL+K to cut the line, line 2 disappears, which is OK (6) paste the line by pressing CTRL+U EXPECTED: line 2 appears again and the whole document looks exactly like in (3) ACTUAL: no visible change. the view shows line 1 line 3 Although the line is actually there in the document. The line appears, when a redraw is triggered somehow, e.g. by resizing the terminal view.
Correction of ACTUAL: the line 2 is pasted over the line 3. The line 3 should be visible too. The view shows line 1 line 2 After resizing the terminal view, it shows correctly line 1 line 2 line 3
Created attachment 272350 [details] terminal.debug file I can reproduce this on MacOSX. The problem is, that the Eclipse Terminal only supports a small subset of escape sequences - roughly the "ANSI" terminal subset, which is actually sufficient to drive most applications. But in order to support proper copying of wrapped lines on a command-line, we announce "xterm" support (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=453393#c1 ). Applications like nano may now use "xterm" escape sequences which the Terminal doesn't understand. Workaround: ----------- export TERM=ansi Then run your application, e.g. nano Deeper Analysis: ---------------- You can use attached "terminal.debug" file to enable terminal tracing: eclipse -data $PWD/terminal.ws -debug $PWD/terminal.debug Now run your test case, the terminal's interpretation of escape sequences is printed to stdout and the original escape sequences are found in the file $PWD/terminal.ws/.metadata/.plugins/org.eclipse.tm.terminal.control/tmterminal.log Running the nano test-case, I see this in tmterminal.log when Ctrl-U is pressed: VT100TerminalControl$TerminalKeyHandler.keyPressed:1165: stateMask = 262144 VT100TerminalControl.sendChar:634: sending '21' LoggingOutputStream.write:27: Received 37 bytes: '\x1b7\x1b[4;11r\x1b8\x1bM\x1b[1;13r\x1b[4;1Hline 2\r\x1b[5d' VT100Emulator.processNewText:282: entered VT100Emulator.processNewText:384: Unsupported escape sequence: escape 'M' '21' is the ASCII code for Ctrl-U. In response, nano sends the escape sequences for "save cursor", "set scroll region 4;11", "restore cursor", escape 'M' where the escape-M means "delete one line" (at the bottom of the scroll region from line 4 to 11, thus scrolling down the "line 3" text to make room for "line 2". Since the "escape M" is not implemented, it doesn't scroll down and line 3 is over-typed. If somebody wanted to implement the missing feature, I think a "deleteLine" would need to be written similar to the "processNewLine" here: http://git.eclipse.org/c/tm/org.eclipse.tm.terminal.git/tree/plugins/org.eclipse.tm.terminal.control/src/org/eclipse/tm/internal/terminal/emulator/VT100EmulatorBackend.java (since processNewLine does just the opposite - insert a line). Then, the new Esc M handling would need to be hooked into the "switch" around line 380 here: http://git.eclipse.org/c/tm/org.eclipse.tm.terminal.git/tree/plugins/org.eclipse.tm.terminal.control/src/org/eclipse/tm/internal/terminal/emulator/VT100Emulator.java Contributions would be most welcome !
PS: A good reference for the xterm escape sequences is https://www.xfree86.org/4.8.0/ctlseqs.html
Hi Martin, thanks having a look. I can conform that the workaround with TERM=ansi works well for me. This issue annoyed me the most during interactive rebases. So, I created a wrapper script ~/bin/nano.sh with the following content #!/bin/bash export TERM=ansi nano "$@" and then, in ~/bashrc, I added export EDITOR=~/bin/nano.sh With the above in place, I can reorder the lines in the rebase document without any problems.
The Terminal component of the Eclipse Ecosystem has a new home. The Terminal is now part of the Eclipse CDT project[1]. This change means a new Git repo[2], P2 site[3] and Bugzilla component. The terminal will continue to be delivered as part of the quarterly Simultaneous Release of Eclipse as well. The marketplace entry[4] had not been updated in a few years. It will once again install the latest release of the terminal on the latest release of the whole IDE (currently 2020-03). If this bug is no longer relevant, please feel free to comment or close the bug. If you can confirm if this issues still occurs in the latest release please do let me know in a comment. [1] https://wiki.eclipse.org/CDT/User/NewIn911 [2] https://git.eclipse.org/c/cdt/org.eclipse.cdt.git (in the terminal directory) [3] current release is 9.11 - P2 site https://download.eclipse.org/tools/cdt/releases/9.11/ [4] https://marketplace.eclipse.org/content/tm-terminal (This comment was added to all open terminal bugs along with changing the Product/component pair to CDT/terminal.)
