If I have an ohmyzsh theme that uses %~/ to get the current directory path. Is there a way to tell it that if the line length requires wrapping onto a new line, to use just the current directory without the full path?
Not exactly, but Zsh can actually do something better than that! You can use %-X<Y<Z%<< to ensure you always have at least X characters remaining after your prompt, by trimming the left side of Z and replacing the trimmed part with Y. (Note that Y itself is always printed literally and any prompt escape sequences inside it will not be expanded. If you want to style Y differently from Z, you will have to put the prompt escapes before and after %X<Y<.)
For example:
PS1=$'\n%-40<...<%~%<<%# '
What this does:
If expanding %~ would leave 40 or more characters of empty space on the line, then expand it in full.
Else, print a ... to the left of %~ and trim off characters from the left of %~'s expansion until our prompt leaves exactly 40 characters of empty space on the line.
Always expand %# after this (since it occurs after %<<).
The nice thing about this is that it works for the current prompt even when you resize your terminal. Just try it and you'll see it will dynamically add or remove characters as you resize.
Related
Is there a ASCII character that does the 'opposite' of backspace, i.e., that moves the cursor one position forward? Id like a character X such that
print("bad\rXbc")
prints bcd (the example is python, but this should be rather a subject depending on the terminal emulator). X cannot be a white space, for the white space overwrites:
print("bad\r bc")
prints cd. In princible, \t does what I want, but the sought character should move by only one character forward. Does it exist?
Edit. To make my question clear: the BS does not delete printed characters, in the sense that they are still visible unless overwritten. Of course this depends on the terminal emulator. For the macOS terminal, this is the case:
I am on Ubuntu and use Gvim. Based on my understanding,I have set tab to expand to 4 spaces. I did not even touch the line that has create_namespace but git diff shows it as shifted by a character. It seems perfectly fine in the editor or when I run cat. Same issue is when I added a new line of txt cluster_token and it shows as shifted by a character in git diff. I have wasted hours trying to understand this silly issue but no clue. What is the issue and how do I fix it?
- echo "--create_namespace"
+ echo "--create_namespace" //Did not even touch this line
echo "--all"
echo "--custom_merge_pipeline_commands"
+ echo "--cluster_token" //Looks fine in editor
If this is TL;DR, skip down to the bolded text below.
As I noted in a comment, the issue of spaces vs tabs sets off flame wars, so I'm going to attempt to be completely neutral on the subject. (Note: I did say attempt. :-) ) It's also worth covering a bit of history, i.e., how we got here in the first place. Also, there is an entirely separate, though currently beta, StackExchange web site devoted to vi / vim at https://vi.stackexchange.com/ so I am not going to get into the many vim settings available here.
First, note that tabs go back to the days of mechanical typewriters (well, probably even before then).
Different models had different features, but most had a key labeled TAB that, when pressed, caused the platen—the rubber roller that holds the paper—to slide leftward (assuming a Western-style, left-to-right carriage typewriter) from its current position to the next tab stop. Tab stops were set mechanically, since all of this was run by wires and springs. Since the type bars would always strike the paper at the center where the ribbon was held against the paper, sliding the platen leftward has the effect of making the next character come out somewhere to the right. How far to the right, depends on the current column and, of course, the tab stop settings.
Early computer interfaces used or emulated mechanical typewriters—well, more precisely, teletype interrfaces—sometimes complete with the exact same mechanically-controlled tab stops. When glass ttys came out, they tended to emulate the existing TTYs. Over time, the terminals got smarter, to the point where some had software-adjustable tab stops.
Others, however, limited tab stops in software to simply "every N columns", where N was variable. DEC chose 10 for some of their early systems, but 8 proved more popular and became the default. Here, sending an ASCII TAB (code 9 decimal) byte to the display terminal caused the terminal to move the cursor from whichever column it was in now, to one up-to-but-not-exceeding N (usually 8) characters to the right. (The behavior of a cursor close to the end of the physical screen line varied, and still varies in software emulations, but the VT100 behavior is pretty common now.)
We no longer use any of these bits of hardware—at least, not commonly—but we do emulate them. Pressing the TAB key in an editor tends to move the cursor to "the next tab stop", wherever that may be. Terminal emulators will emulate whatever terminal—often, again, the VT100, which has variable tab stops (set via escape sequences) but defaults to every eighth column (columns 9, 17, 25, and so on, if we number the first column 1—as is traditional—instead of the proper mathematical column zero :-) ).
For storing text in files, however, there is an option: we can store the literal ASCII TAB character (or the Unicode equivalent which is U+0009), or we can store however many spaces it might take to get to the selected column. If we store a literal TAB, it is up to whatever it is that displays the file to choose which column is the desired column. If we store literal space characters, whatever is displaying the file must display that many space characters.1 The effect is that if we store literal TABs, the display depends on previous output (since the cursor column depends on previous output), but if we store literal spaces, it does not.
Meanwhile, when git diff displays lines, it inserts one character in front of each line. If the line being displayed starts with a literal TAB followed by the word old, what happens is that git diff writes a space or plus or minus character, then a TAB, then the next character. Assuming your terminal has its tab-stops at columns 9, 17, 25, and so on, the character after the TAB shows up in column 9:
0 1
1234567890123456789
- old
If, on the other hand, the line in the file starts with eight spaces followed by the word new, what you see is the git diff character, then eight spaces, then the word in column 10:
0 1
1234567890123456789
+ new
Stacking these atop one another we get:
0 1
1234567890123456789
- old
+ new
which is what you are seeing. This means that your claim:
- echo "--create_namespace"
+ echo "--create_namespace" //Did not even touch this line
is at best half-true: you might not have touched the line, but your editor did. It replaced at least one literal TAB character with spaces. (We cannot tell from here how many such characters were changed—perhaps, for instance, it replaced one TAB with four spaces, leaving four existing spaces in place, if you have everything rigged up to use columns 5, 9, 13, 17, and so on.)
1It is now time to avoid an entire separate aside on fixed vs variable pitch fonts. :-)
I have a file with only one single line of content inside, but this line is very very long.
When I open it up in Vi, it fills up the whole screen.
How could I move the cursor by number of words or bytes so I can see the content of the next 'page'.
If your goal is to navigate down a single wrapped line, you should consider using g before motions. For example:
gj: go down one line visually
g8j: go down 8 visual lines
You could also move to a specific index in the line with |, e.g. 10| to go to character 10 (one-indexed).
w will move you over words (delimiting with certain punctuation), while W will move you over whole words, not counting certain punctuation. Combine with number prefixes to "scan" around.
If you'd prefer not to see your text wrapped and filling the screen, you can call :set nowrap and move with standard motions (e.g. w and W for moving words). Moving the whole window, with zl, zh, zj, and zk are options too.
Pressing l takes you to the next character.
Pressing w takes you to the next word.
If you prefix those with a number, you can specify how many words or characters you want to move, e.g. 1000w.
Maybe for such a thing you shouldn't use vi (but I don't want to start a religious war here).
I have a random problem which I personally find quite irritating. I use the terminal alot and have installed a theme and even toyed around with what is displayed on the prompt. However if I write a particularly line of text it does not start a new line in the terminal instead it will begin overwriting what is displayed on the screen in the current terminal line. I wondered if anyone knew a way to solve this so that it does show a new line and all input would be visible.
PS1 value
export PS1="\r\n\e[1;32mdave:\w $\e[0;37m "
Well, thanks to the post by #Joni, I believe the solution is:
PS1="\r\n\[\e[1;32m\]dave:\w $\[\e[0;37m\] "
That is, here the color codes \e[1;32m and \e[0;37m are enclosed within \[ and \], as #Joni suggested they should be.
Non printing characters, like escape codes for color, have to be surrounded with \[ and \] so that bash knows to exclude them when calculating the length of the line.
http://www.tldp.org/HOWTO/Bash-Prompt-HOWTO/nonprintingchars.html
Edit: This question had been tagged "Tolstoy" in appreciation of the quality and length of my writing:) Just reading the first and the last paragraph should be enough:) If you tend to select and move code with the mouse, the stuff in middle could be interesting to you.
This question is about how you use text editors in general. I’m looking for the best way to delete a plurality of lines of code (no intent to patent it:) This extends to transposing lines, i.e. deleting and adding them somewhere else. Most importantly, I don’t want to be creating any blank lines that I have to delete separately. Sort of like Visual Studio's SHIFT+DELETE feature, but working for multiple lines at once.
Say you want to delete line 3 from following code (tabs and newlines visualized as well). The naïve way would be to select the text between angle brackets:
if (true) {\n
\t int i = 1;\n
\t <i *= 2;>\n
\t i += 3;\n
}\n
Then hit backspace. This creates a blank line. Hit backspace twice more to delete \t and \n.
You end up with:
if (true) {\n
\t int i = 1;\n
\t i += 3;\n
}\n
When you try to select a whole line, Visual Studio doesn't let you select the trailing newline character. For example, placing the cursor on a line and hitting SHIFT+END will not select the newline at the end. Neither will you select the newline if you use your mouse, i.e. clicking in the middle of a line and dragging the cursor all the way to the right. You only select the trailing newline characters if you make a selection that spans at least two lines. Most editors I use do it this way; Microsoft WordPad and Word are counter-examples (and I frequently get newlines wrong when deleting text there; at least Word has a way to display end-of-line and end-of-paragraph characters explicitly).
When using Visual Studio and other editors in general, here’s the solution that currently works best for me:
Using the mouse, I select the characters that I put between angle brackets:
if (true) {\n
\t int i = 1;<\n
\t i *= 2;>\n
\t i += 3;\n
}\n
Hitting backspace now, you delete the line in one go without having to delete any other characters. This works for several contiguous lines at once. Additionally, it can be used for transposing lines. You could drag the selection between the angle brackets to the point marked with a caret:
if (true) {\n
\t int i = 1;<\n
\t i *= 2;>\n
\t i += 3;^\n
}\n
This leaves you with:
if (true) {\n
\t int i = 1;\n
\t i += 3;<\n
\t i *= 2;>\n
}\n
where lines 3 and 4 have switched place.
There are variations on this theme. When you want to delete line 3, you could also select the following characters:
if (true) {\n
\t int i = 1;\n
<\t i *= 2;\n
>\t i += 3;\n
}\n
In fact, this is what Visual Studio does if you tell it to select a complete line. You do this by clicking in the margin between your code and the column where the red circles go which indicate breakpoints. The mouse pointer is mirrored in that area to distinguish it a little better, but I think it's too narrow and physically too far removed from the code I want to select.
Maybe this method is useful to other people as well, even if it only serves to make them aware of how newlines are handled when selecting/deleting text:) It works nicely for most non-specialized text editors. However, given the vast amount of features and plugins for Visual Studio (which I use most), I'm sure there is better way to use it to delete and move lines of code. Getting the indentation right automatically when moving code between different blocks would be nice (i.e. without hitting "Format Document/Selection"). I'm looking forward to suggestions; no rants on micro-optimization, please:)
Summary of Answers
With respect to Visual Studio: Navigating well with the cursor keys.
The solution that would best suit my style of going over and editing code is the Eclipse way:
You can select several consecutive lines of code, where the first and the last selected line may be selected only partially. Pressing ALT+{up,down} moves the complete lines (not just the selection) up and down, fixing indentation as you go. Hitting CTRL+D deletes the lines completely (not just the selection) without leaving any unwanted blank lines. I would love to see this in Visual Studio!
In Emacs:
kill-line C-k
transpose-lines C-x C-t
C-a C-k C-k -- kill whole line including newline (or kill-whole-line by C-S-backspace).
C-u <number> C-k -- kill <number> of lines (including newlines).
C-y -- yank back the most recently killed text (aka paste)
In VIM:
Delete the whole line including the newline: dd
Transpose lines: dd p
You can always prefix any command with a number to repeat it, so to delete 10 lines do:
10 dd
You can also specify a range of lines to delete. For instance, to delete lines 10-15:
:10,15d
Or you can move the lines, for instance move lines 10-15 below line 20:
:10,15m20
Or you can copy the lines:
:10,15t20
What I do is, starting with the cursor at the start of the line (in some editors you have to press home twice to do this), hold shift and press down until all lines that I want to delete are selected. Then I press delete.
In Eclipse you can ALT-↓ or ALT-↑ to move a line. I find this incredibly useful, as well as ALT-SHIFT-{↓, ↑} to copy a line. In addition, it doesn't wreck your clipboard. It even corrects indentation as the line is moving!
Adding to the existing vim answer, you can use d along with any cursor movement command to delete from the cursor's current position to the new position. For example, to delete...
...to end-of-paragraph (usually meaning "to the next blank line"): d}
...the line containing the cursor and the next 5 lines: d5j
...a set of parentheses, braces, etc. and its contents: d% (with the cursor on the opening or closing paren/brace/etc.)
...to the third appearance of the word "foo": d3/foo
It's quite flexible.
Learn to use your cursor keys.
For moving lines I do the following:
Use ↑/↓to move to the line you want to copy.
Hit Home if not there already, and again if it places the cursor after whitespace.
Then press Shift+↓ to select the line (or lines) you want to move
Ctrl+X to cut the line.
Move Up/Down to the line you want to insert
Ctrl+V
This should work in pretty much any text editor on Windows.
When deleting lines I still tend to use Ctrl+X (although I guess I also use backspace) as the above is so ingrained in how I edit, and it's also more forgiving.
(Although I find them disorienting on the occasions I use Macs, I think Apple might have been on to something with the way they've set up the Home/End, skip word shortcuts on Macs)
Ctrl+Shift+L removes line without copying it to the buffer.
in Eclipse i use CTRL+ D to delete a single line (or a couple)
for many lines i'll select them with the mouse or with SHIFT + ARROW then press the DEL key.
In addition to the above, use Resharper for Visual Studio to do what you want. Best VS plugin you will find ever. It provides a bunch of different commands that help with moving/deleting/copying code here there and everywhere. Not to mention refactor/generate/etc code.
Ctrl-Shift-Alt ↑or ↓ will move a method up or down, line up or down, etc.
Shift-Del - deletes the current line, but puts it in the clipboard (unless you modify your settings to not do this - I'm trying to recall if this is a VS standard shortcut, not just Resharper - been too long).
Ctrl-C, Ctrl-X without selecting copies/cuts the current line.
And on and on...
See http://www.jetbrains.com/resharper/docs/ReSharper40DefaultKeymap2.pdf for a full list.
Using the Brief keyboard mapping this is done using the Alt+L to mark the line and the - key on the numeric keypad (or Alt+D) to cut the line to clipboard. The cut will remove the line entirely, including the newline character.
Hitting the Ins key on the numeric keypad would put the line back into the document including the newline character.
IMHO Brief is a really well designed keyboard mapping.
PS: I think MSVC has an option to emulate the Brief keyboard mapping.
In Emacs, in addition to C-k (and C-k with a numeric prefix arg, to kill N lines), you can just use the mouse:
To kill one line: triple-click it, then right-click twice
To kill multiple lines: triple-click the first line, then right-click on the last line ("first" line can be after the "last" line -- "first" here means first one you click)