I would like to turn off word wrap in my vscode terminal so I can more easily view compiler messages.
e.g.
Imagine this is a very long line generated from a compiler and it has a lot of information and when it word wraps it is very hard to read so I would like vs code to just have a scroll bar at the bottom like SO has here.
However, after attempting several different methods of disabling word wrap, what is actually generated looks like:
Imagine this is a very long line generated from a compiler and it
t has a lot of information and when it word wraps it is very hard to read so I would like vs code to just have a scroll bar at the bottom like SO has here.
(extra t on the second line is intentional)
So it appears that I've managed to turn off word wrap internal to vscode, but something is still causing a carriage return (with no line feed), I think?
These messages are produced by running a C++ build task in the integrated terminal that in turn calls cmd.exe to run a script (e.g. cmd.exe <build command script>
Here is what I've tried so far:
First thing I tried was turning off word wrap in vscode (alt + z, or View > Word Wrap). This led to the weird line break described above.
I was suspicious that cmd was the one causing this weird line break, so I disabled "wrap text output on resize" and set the screen buffer width manually to 1000 (1000 >> greater than any of my output lines) within
command prompt properties for both "properties" and "default". I then tested the same command running in my vscode terminal and it worked as expected in the cmd terminal but still not vscode.
I was suspicious powershell (which I think vs code uses in it's integrated terminal?) was the one causing the line break, so I set the properties the same as in the cmd image above. Again this worked as expected in the powershell terminal, but still not vscode.
Following this, I changed the "terminal fixed dimensions" using the command from the command pallet and set the width to a matching column width of 1000 (leaving row empty for "automatic").
I've tried restarting vscode and my pc between several of these steps with no change.
What could be causing this behavior inside of the vscode terminal?
I am using Clink for Windows and it works mostly fine in the integrated terminal from VSCode. Since it is invoked via ctrl+space I tried removing all related VSCode keybindings. With shift+alt+? (clinks keybinding browser) I found that VSCode sends the wrong keystrokes when pressing ctrl+space:
C-# : set-mark -- Set the mark to the cursor point. If a numeric argument is supplied, sets the mark to that position
When I am in a normal terminal I get:
C-Space : clink-select-complete -- Perform completion by selecting from an interactive list of possible completions; if there is only one match, insert it
The Problem:
The problem is that when I change the cursor PowerShell 7.1.3 to the "Vertical Bar" but then as soon as I type something or press enter in the terminal the cursor changes back to "Legacy Style".
Things I have tried:
I have tried removing the module PSReadLine by using Remove-Module PSReadLine but when I do that it removes the syntax highlighting which I want to keep, and of course this does solve the problem of the cursor but as I said before I want to keep the syntax highlighting because it looks very nice.
I know you can pick pwsh.exe in vs code default terminal and then pick the "Vertical Bar" option in the settings for the terminal but I don't want to open vs code every single time I want to use the terminal.
Is there a way to keep both the syntax highlighting and remove the cursor problem without removing the PSReadLine module?
Why does tmux change the terminal from xterm to screen, and how can I fix the resulting text color change in emacs? I think the easiest way would be to prevent it from changing to screen in the first place.
I can use TERM=xterm emacs file.ext to do it temporarily, but that's just a workaround that doesn't solve the root of the problem.
Furthermore, the function keys no longer work in emacs when using tmux. Instead of F3 and F4 being macro shortcuts, they just print a tilde as they would in the shell. This seems unrelated to xterm/screen mentioned above. What is happening here, and how I can fix this?
tmux sets TERM to screen because that terminal description is limited to things that tmux knows how to work with. Like screen, tmux translates features from the outer terminal description to the inner.
If a special key (function-key, cursor-key, etc) does not have an exact match in the terminal description, tmux will ignore it.
The default configuration for PuTTY sends different escape sequences for F1-F4. The sequences which PuTTY sends are not in the terminal description for xterm.
Here's a comparison of the two (as a CSV file, but readable enough):
NAME,putty,xterm
kf1,\E[11~,\EOP
kf2,\E[12~,\EOQ
kf3,\E[13~,\EOR
kf4,\E[14~,\EOS
kf5,\E[15~,\E[15~
kf6,\E[17~,\E[17~
kf7,\E[18~,\E[18~
kf8,\E[19~,\E[19~
kf9,\E[20~,\E[20~
kf10,\E[21~,\E[21~
kf11,\E[23~,\E[23~
kf12,\E[24~,\E[24~
kf13,\E[25~,\E[1;2P
kf14,\E[26~,\E[1;2Q
kf15,\E[28~,\E[1;2R
kf16,\E[29~,\E[1;2S
kf17,\E[31~,\E[15;2~
kf18,\E[32~,\E[17;2~
kf19,\E[33~,\E[18;2~
kf20,\E[34~,\E[19;2~
You'd have trouble getting PuTTY to send F13-F20, but will certainly run into trouble using PuTTY and tmux with TERM=xterm.
Regarding colors, the same issue applies. The screen terminal description tells applications that the terminal can support 8 colors, and tells how to display those eight colors. If your external terminal can do more, then tmux and screen hide that.
The conversion is not perfect. GNU screen has a feature where it looks for a corresponding screen.$TERM terminal description (i.e., concatenating the outer TERM value to screen). tmux does not do that: it makes assumptions regarding xterm. But PuTTY is not xterm...
ncurses has several of those concatenated terminal-names for terminal descriptions, but no one has suggested a way for tmux to use them automatically.
When I open files with emacs it adds 12;rgb:1c1c/1c1c/1c1c on the top. How can I prevent this?
I have installed emacs on a clean reinstalled debian system.
Emacs: GNU Emacs 24.4.1
Terminal Emulator: MobaXterm Personal Edition v7.7
System (local): Windows 7 Ultimate
System (remote): Debian 8.0 "jessie" stable
As noted, "MobaXterm" is not "xterm". According to its webpage it is
Based on PuTTY/MinTTY with antialiased fonts and macro support
Lacking a detailed change history, and the problem reported by the OP, it seems that MobaXterm is based on PuTTY from a while back, and does not implement all of the control sequences which PuTTY does, much less those of xterm.
The particular sequence which is not recognized (referring to XTerm Control Sequences) may be this:
OSC Ps ; Pt ST
OSC Ps ; Pt BEL
...
Ps = 1 2 -> Change text cursor color to Pt.
That is part of a group of controls predating ANSI color support in xterm, referred to as dynamic colors.
Based on comments in other places, it seems that the problem could lie within the OP's Emacs configuration, by using scripts which do an ad hoc test of TERM to decide if it can do colors, rather than inspecting the terminal capabilities. See Terminal emacs colors only work with TERM=xterm-256color where someone worked around this problem by modifying their init.el to add special cases for rxvt and xterm.
Emacs of course is capable of doing colors in different terminals. See emacs colors based on $TERM environment variable for comments. And TERM=xterm on Debian has provided color for quite a while. So in a typical configuration, color should "just work".
However, there are different ways to configure Emacs. Attempting to reuse some 256-color script can fall into the hole dug by developers who assume that every terminal is just like the one in front of them. See the Emacs wiki page X Term Colors for an example.
!! SOLVED IN MOBAXTERM VERSION 8.2 !!
Looks like your terminal settings are out of sync. The settings of your terminal need to agree with the termcap/terminfo settings on the server. Try to set the TERM variable in the shell on the server to a value which better matches the terminal emulation capabilities of your terminal (common values are xterm, xterm-color, vt520, and vt102) or correspondingly change the settings of the terminal to match the current TERM value. (If the terminal is buggy, you may need some trial and error to find a mode which works well for you.)
VT220 works fine; Edit Session / Terminal Settings / Type: vt220