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?
Related
Is there a method to store the command line outputs to a file in Julia.
The command history can be seen at .julia\logs\repl_history.jl in Windows OS.
I wish to store command line output also to a file automatically.
? command outputs also.
Whatever is shown in the julia command line, the whole text should be stored into a file.
Is there a way to do this.
found a similar qn : For Julia saving output to txt/CSV file?
If you run Julia in REPL mode in Widows using PowerShell, you can do the following in PowerShell:
Open the left upper corner menu and in Defaults, change the buffer size to something large enough for your needs, say 500.
After running Julia to do what you need, go the the left hand corner menu and choose Edit - Select all, then Copy. Paste to an editor.
My problem is as follows. When copying multi-line text (consisting of commands, for example) from somewhere (text editors, etc.) to the terminal via Ctrl + Shift + V or through the menu with the right mouse button, extra empty lines appear between each line.
For me, this is a problem when copying, for example, the body of a function to the Python interpreter.
My system is Linux Manjaro-KDE (5.4.43-1-MANJARO kernel), but the problem repeats in Arch-linux-KDE too (I checked this).
I managed to figure out the following on my own:
When copying multi-line text, in the Clipboard (which I view by clicking on the corresponding tray icon) a blue “Enter” icon is in front of each new line of the text.
If I edit the block with text directly in the Clipboard buffer, for example, press "edit", do nothing and just save, then the blue "Enter" disappears and the text is copied to the terminal without any extra intermediate lines.
As for other editors and exactly for the gnome-terminal, the text is copied everywhere correctly without blank lines, regardless of the "existence" of the blue "Enter" in the Clipboard. In addition, if I copy lines from the terminal itself and paste into it, then empty lines do not appear.
I think that additional CR/LF characters are added, which are perceived by a single line break everywhere except for the terminal "org.kde.konsole".
Please help: how can I change the behavior of the buffer when copying or the behavior of the terminal?
This question is similar to https://forum.manjaro.org/t/copy-paste-multiple-lines-on-yakuake-konsole-adds-newlines/94589 but it didn't help me.
Had the same problem, it was fixed in Konsole 20.04.3 by the following commit: https://invent.kde.org/utilities/konsole/-/commit/6b6a1e552492a25217cded1d83c25a652e5b249a
Assume I want to invoke a tool with a lot of options, like:
$ somescript --option1 --option2 --option3 --option4 --option5 whatever even more stuff
But the width of the terminal doesn't allow to have that thing on a "single line".
That alone isn't a problem, but with fish, there is a problem with scrolling.
When I enter that extra-wide command, at some point, there will be a line break:
$ somescript --option1 --option2 --option3 --option4 --option5
whatever even more stuff
All fine so far. While typing such a lengthy command, I can scroll forth and back at any point. Works as expected. So, assume I entered the command, made a mistake, and now want to remove --option4.
The normal thing: use "arrow up" to get to that command in the history, to then use "arrow left" to scroll within the command. And now something weird happens.
Everything is fine while the cursor is within the second line. But when the cursor moves to the first line ... after 3 to 5 more "arrow left" strokes, the cursor moves UP another line. Then it sits above the first line of the command. There is also a vertical jump of a few characters.
In other words: as soon as a command is longer than the width of the terminal, I am unable to scroll into the first line reliably. The cursor shows up somewhere, and it is really hard to guess where it really sits at any moment. Which makes it almost impossible to edit anything in that first line.
This is on MacOs, using iterm 3.2.9 and fish version 3.0.2 installed via brew.
Wrote up defect 6014 on github. Outcome is rather frustrating.
The problem is: the Mac terminal(s) all handle certain unicode characters the wrong way. "Normally" that isn't a problem, but when you use one of those fish prompts that give you the git status (like AcidHub which is my favorite) ... fish can't compute/determine the exact line width, and there you go.
So, basically, when using fish on MacOs, option space is limited to:
use the defaults, which (when using special prompts, like AcidHub will lead to scrolling issues)
adapt the fish prompt accordingly (in my case, I replaced all special unicode chars with something simpler). It doesn't look that great, but scrolling simply works again.
And a completely different and unexpected solution to the problem: I am using iterm2 on my Mac, and iterm2 just added a "status bar" section. That can be easily configured, and of course, it already has a status bar component that tells you about git status.
Thus my solution: I changed the fish prompt to just give the PWD, and all the other things that the AcidHub prompt has to offer, are now "iterm2 status bar" components!
A lot of the code that I write in Matlab has a very verbose output. As the program runs, information is printed to the command window, and with each new line, the window automatically scrolls to the bottom. This becomes a problem when I want to read some of the output more closely or scroll up to look at older output. I can scroll up, but only until a new line is printed, which is often less than a second.
Does anyone know if it is possible to turn off this automatic scrolling in the Matlab window? I work in a number of different Matlab versions, depending on the machine, and this happens with all of them. The answer to this might be "No", but I swear I remember having this functionality at one point.
Use the more function: http://www.mathworks.com/help/matlab/ref/more.html
more on
Then run your program. Press spacebar when you wish to see more of the output.
more off will turn it off.
You may find this workaround useful.
First launch matlab using the command line matlab -logfile 'myLog.txt' (the doc says it "starts MATLAB and makes a copy of any output to the Command Window in filename. This includes all crash reports.")
Then open your .txt file using a text editor supporting automatic refresh of content (see picture). On OSX I use TextWrangler (freely available at www) but others have been reported to have this feature (see here or here).
Results: output displays (fprintf, disp, but not the commands per se) are printed both on the Matlab console and the text editor (file is refreshed with a little lag time, below half a second I would say with my configuration). And there is no automatic scrolling. Such procedure does not seem to impact the overall performance of the script (although it may deserve some testing).
Context
Have some transcript files from terminal interaction, obtained using traditional Unix command "script".
Those transcripts contain lots of control character (like backspace when editing shell commands), and lots of color code sequences as result of running various commands. Occasionally, even colorful full-terminal (ncurses-based) applications like "emacs -nw" or "aptitude" were run.
At program runtime, TERM environment variable was set as "xterm".
Need 1: read (more or less solved)
I need to read those files again and sometimes copy-paste some small parts.
The trouble is : while one color change here and there is not so much of a problem, their actual density makes the output barely readable. Worse, edited command lines (with cursor jumps and edited words) are completely unreadable.
"Okay" solution
Browse through files using e.g. "less -r". Paging forward in the same terminal setup reproduces the various color and character style.
But many other features come out more or less broken, e.g. search backwards produces jumbled terminal output, often have to pres "Ctrl-L" to clean thing up.
Need 2: editing
My preferred editor is emacs. Some people have had a similar situation when running the shell inside emacs, e.g. Something wrong with Emacs shell.
Here is not the same situation. Examples of differences: here we don't have to run an actual shell, but we need to move cursor freely like in usual editing.
Editing here means easily open such a transcript file in editor and then:
at all times through editing, see character changes (color, attributes) as conveyed by the terminal codes
(optional) some character that are neighbour on the terminal grid but are separated in file by some control characters would have a visual hint about this
ability to insert some text,
delete sections,
use all editor features like search/replace etc.
copy & paste to & from file (including to external programs, which would receive just plain text)
in my wildest dreams, some kind of "flatten" action, like select a sequence with a heavily edited command line and replace it with a simple series of characters as if it was typed in one run. "Visual hints" mentioned above would disappear.
Type Alt-: to evaluate something in the minibuffer. Evaluate (ansi-color-apply-on-region (point-min) (point-max)) and it will convert ansi color codes to be font colors.