I have been playing around with the ansi colours in OSX terminal (bash v.3.2.57, Yosmite).
I have a problem with background colour behaviour once I fill up a terminal-window (as in, when it scrolls down).
The background colour will fill the right hand side white space, whilst also "skipping" a line (see picture). It works as I want it to until the output makes the window scroll. If I use the "clear" command the output will look fine until the output fills up a terminal window again.
The code below was simply getting the different combinations of colours (I truncated it a bit for this problem).
I have a feeling terminal is to blame rather than python, because the output works initially. Can anyone explain this behaviour? Cheers.
#coloured text in terminal
#ANSI escape sequences
std_txt = '\033[0m'
print('colour test' +'\n')
print(' X in 033[0;Xm')
for x in range(30,35):
print ''.join(["\033[0;",str(x), 'm']) + 'test' +'\t' + str(x)
print std_txt +'\n' + ('end')
print('colour test 2' +'\n')
print(' X in 033[0;30;Xm')
for x in range(40,45):
print ''.join(["\033[0;30;",str(x), 'm']) + 'test' +'\t' + str(x)
print std_txt +'\n' + ('end')
ps: What I mean by filling up a terminal window or scrolling.
If your terminal-window is 80x24, filling it up will be using 24 lines, and >25 would make it scroll. Sorry, I found it hard to explain this in the problem.
The problem is that you're not resetting the color before the newline, so the terminal tries to be helpful.
Change
print ''.join(["\033[0;30;",str(x), 'm']) + 'test' +'\t' + str(x)
To:
print ''.join(["\033[0;30;",str(x), 'm']) + 'test' +'\t' + str(x) + std_txt
Related
I first do a vimdiff on two files, but they are vertically split, which makes it hard to read. I want to switch to horizontal split. I tried:
control + w then J or h, which doesn't effect at all
I also tried:
command + w, which asked 'Do you want to terminate processes in this tab?'
I got stuck here. What's wrong with me?
This is a regular diff, $ vim -d foo bar, with the foo window active:
Here is how it looks after pressing <C-w>J, that is Control+w then Shift+j:
Notice the active window is now at the bottom.
From the same starting point, here is how it looks after pressing <C-w>K, that is Control+w then Shift+k:
Notice the active window is now at the top.
See :help window-moving.
To split the screen horizontally:
a.) Hit CTRL + w
b.) and then s.
If you want to navigate between the screen:
a.) Hit CTRL + w
b.) and then w.
To exit out of one of the screen:
a.) Go into command mode (i.e. hit ESC)
b.) and quit as usual: :q.
To split the screen vertically, much like splitting horizontally:
a.) Start by hitting CTRL + w.
b.) but then hit v (instead of s).
Navigating between the split screens is the same (CTRL + w + w).
What I want to do is gray out text with a pound sign (#) in SublimeText, therefore the code will not be read over. This used to be a feature, but no longer works, however.
Do you mean the how to comment out in Python using Sublime text? You can just select the lines you want to comment out and then press ctrl + / (in Windows) or cmd + / (in MacOS)
I wrote more than 7 programs that is expected to print more than 296 lines in the command line. But my windows pc (32bit with Code::Blocks IDE) only prints 296 lines each time. One of the code was:
for (int x=0; x < 300; ++x)
cout << x << "\n";
First number the program above printed was 4 (I don't know what it does with 0,1,2 and 3) and last number was 299 in 296th line. I guess something is limited there. But what, ostream in c++, my IDE or the command prompt itself?
Since the method you used to check what number were output was by scrolling back in the command window, you're not seeing the first part of your output.
The scrollback window has a limit to the number of lines it keeps around. After you run your program and scroll back to see the number 4, press enter 4 times and scroll back again. The number will now be 8. This doesn't mean your program didn't print the numbers 0 through 7.
If you right-click on the command prompt window's title bar and select Properties, go to the Layout tab. There is a place to specify the scrollback buffer size. It appears the default is 300, since I've never changed this setting.
I am parsing a csv file and the file has "\t" characters after every column. Why is it that when I print out the individual lines in terminal or open the file in my text editor that the tab spacing between each of the columns is different?
When you use tab, you're essentially moving to the next tab location, not moving over a specific distance. To see the difference, try using 4 spaces instead of tab. Or, alternatively, run the following code, and I think it may become clear to you.
puts "Hel\tlo world!"
puts "H\tello world!"
puts "Hell\to world!"
Hope that helps.
Do you mean something like
1 1
12345678 1
as a result of
puts "1\t1"
puts "12345678\t1"
A tab jumps to the next position in 8-space steps (8 spaces is a common distance, but it depends on settings of your editor. For ruby often is 2-space distance is used).
If the previous text is longer then 8 characters, then you jump to the next position and you have the impression of different tab spacing.
I have followed the guidance in Is there any way in the OS X Terminal to move the cursor word by word? and now in terminal I can move cursor word by word.
However, in Vim, I am only able to move backward word by word. I cannot move forward word by word, no matter I set \033f to option+cursor-right or shift+cursor-right. The only workaround I figured out is to go to normal mode and click <w> to move to next word. Any idea about how to fix that? Thanks.
w is not a workaround. It's the primary way to move word by word (see also: W, b, B, e, E). What you want is a workaround that won't help you learn Vim at all.
Some may argue that moving around with VIM native keyboard shortcuts is not a workaround, but for me it sure is both very inconvenient and very inefficient. Especially the part where you need to switch between insert mode and normal mode just to move to the next word.
That's why I came up with a solution based on this answer on SuperUser. The idea is to map input provided by the Terminal.app directly in VIM. The answer on SU shows what to put into your vimrc file for the Home/End keys to work as expected.
My tweaked version below includes the Option+arrow (or Alt+arrow) navigation on words. I've tried to mimic the behavior of Terminal's moving around as close as I could get. So pressing Option+Right (Alt+Right) will move the caret to the next character after the word (as opposed to the last character of the word, which is VIMs w native bahavior).
let tp=$TERM_PROGRAM
if tp == 'Apple_Terminal'
:" map Mac OS X Terminal.app
" map Home/End:
:map <ESC>[H <Home>
:map <ESC>[F <End>
" small 'o' letter in <C-o> means no exit from the insert mode
:imap <ESC>[H <C-o><Home>
:imap <ESC>[F <C-o><End>
:cmap <ESC>[H <Home>
:cmap <ESC>[F <End>
" map Option+Left/Option+Right:
" for this to work you must have the bindings in Settings > Keyboard set
" as follows:
" 'option cursor left' to '\033b'
" 'option cursor right' to '\033f'
:map <ESC>f el
:imap <ESC>b <C-o>b
:imap <ESC>f <C-o>el
:cmap <ESC>f el
endif
As a small, but significant bonus you get Home/End navigation without exiting the insert mode. Tested on 10.8.5.
Let me clear a few things up for you. Bash (the shell program running inside the terminal) has the behavior you are used to. (Using Alt+f to move forward by word, and Alt+b to move backward by word.) This was originally done to be like Emacs. You can use the command
set -o vi
to switch to vim behavior. In this mode, you can use Esc to switch to normal mode, and move around like in vim; then press i to go back to insert mode.
So don't be surprised that Vim isn't trying to act like Emacs. The whole power behind vim lies behind these simple motions.