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. :-)
Related
Very close to reverse of this question. I prefer coding with 2-whitespace indentation, but need to have files indented with tabs to align with project convention. What I would like to do is preferably automatically convert 2 spaces upon entry to tab symbol in Notepad++ and have the editor configured to tab length of 2.
A possible manual way for doing this could be Edit->Blank Operations->Space to TAB but this converts all of my spaces to tabs, even those of length 1 - which are, for example, spaces between function arguments, not just leading spaces.
In a perfect case scenario I'm trying to achieve formatting style as described in this question, but with typing just spaces and the editor taking care of the rest.
I'm on Notepad++ 6.0, but willing to upgrade if this helps
Let me complete the answer of Ari Okkonen to add a workaround to the problem commented by Sergii Zaskaleta of mixed tabs and spaces at the beginning of the line.
Settings->Preferences->Tab Settings->Tab size: 2 (if not already)
Edit->Blank Operations->Space to TAB (Leading)
Select a block of lines of text with the problem of mixed spaces and tabs. Press [Tab] and [Shift]+[Tab] to add and remove a tab from each line. In the process, the leading spaces had been converted to tabs.
A manual way that seems to work: After having edited the file before saving you may try (Works in Notepad++ v6.8.3):
Settings->Preferences->Tab Settings->Tab size: 2 (if not already)
Edit->Blank Operations->Space to TAB (Leading)
While reading arguments against the use of Tabs, I came across this (source):
...it can be a good idea to avoid tabs alltogether, because the semantics of tabs are not very well-defined in the computer world, and they can be displayed completely differently on different types of systems and editors.
I am relatively new to programming, and have never experienced any issues with tabs in my code, and I've used a number of editors including Notepad++, Programmer's Nodepad, Gedit, Kate, Sublime Text, etc. I may not have done enough coding to get to that point, hence the question:
Can someone please explain, in simple terms, what the quote states? And is the problem with tabs still relevant?
Please note that I am not asking you whether I should use tabs or spaces in my code. I am only after a rational explanation for a specific argument against tabs that I've come across.
I assume you want to see some examples so bellow I've listed some of the most common.
Problem #1: Tab width is not consistent
This is for "displayed completely differently on different types of systems and editors" part.
Even assuming all systems and editors (that your code will be displayed on) agrees on same tab semantics: "move to the right until the current column is a multiple of N", the N is arbitrary.
Historically "standard" for this N is 8 but now most people configure their editors it to be 4 or 2 to "look better".
This is where tab width inconsistency problems come from.
I will use tab widths 2 and 8 in my examples to make differences more visual but same applies to other widths as well.
Indent
Lets say someone is using tab width: 2 in their editor. They see the code like this:
class Foo:
def doSomething(a):
if test(a):
// some nice comment
// about this
bar(a)
Now someone else reads this code in say terminal that uses tab width 8. They see the code like this:
class Foo:
def doSomething(a):
if test(a):
// some nice comment
// about this
bar(a)
That someone may see this as not very pleasant.
Align
So far we have seen inconsistency in indent. But some people like to also align code e.g. assignments, comments.
Again with tab width 2:
class Foo:
def do_something(a):
if test(a):
foo = a.foo // some nice comment
foo_bar = bar(foo) // about this
bar(a)
Again someone else reads this in environment where tab width is 8. Lets say they need to post this snippet to the web and uses <pre> tag. Browsers by default use "standard" tab width 8 and the code looks like this:
class Foo:
def do_something(a):
if test(a):
foo = a.foo // some nice comment
foo_bar = bar(foo) // about this
bar(a)
They can't post it as is. They have to modify the code to replace tabs to spaces.
Line length
Most coding standards define maximum line width.
Lets take max line width 80 for example.
Someone using tab width 2 may see this code completely standard conforming. For them the longest line width is 74 (visible width as opposed to line length in bytes which is 72).
class Foo:
def do_something(a):
// Some very nice comment about code bellow using more then few words.
Someone else using tab width 8 (in a terminal for example) will see the same line as non-conforming because now longest line width is 86:
class Foo:
def do_something(a):
// Some very nice comment about code bellow using more then few words.
Since tab width is inconsistent, line with is now inconsistent too.
Problem #2: Tab is not same thing everywhere
This is for the "semantics of tabs are not very well-defined" part.
So far we assumed that everyone uses tab character as "move to the right until the current column is a multiple of N".
But in some contexts tab character may be used for something a bit different. For example in word processors tab means "move to the the next tab stop", where tab stops are completely arbitrary (and most likely not event the same width).
For example lets say someone is writing a document that uses tab stops:
Now lets say they need to paste some code snippet in it. If code is using tabs, following happens:
They can't leave it as is. They have to modify the code to replace tabs to spaces.
Conclusion
As you can see tabs in different contexts may render code from slightly to completely unreadable.
Spaces have none of the above problems.
I like #Giedrius’ answer (+1), and am going to toss in some vastly over-simplified history just because.
What is a space? It is a blank stretch between letters used to identify words.
How big is a space? It depends on the letters—specifically, on the font. There are thousands of fonts, and they can all be tagged as either proportional or non-proportional. In proportional fonts, character width varies (compare i and M); in non-proportional fonts, character width is always the same (compare i and M). How big is a space? It’s as big as whoever designed the font determined it should be. (Typesetting has been around since Guttenberg, which means the typesetting industry has had a few centuries to figure what works and what doesn’t.)
Skipping a few hundred hears, probably relevant stuff happened that I don’t know about.
Along comes the typewriter (hey kids, ever actually seen one?) These allowed you to type out anything you want to. However, to make it work (totally mechanical, all gears and pulleys, no electricity required, but not cool enough for Steampunk) every character has to be the same width, including the spaces.
Free-form words are all nice and well, but quite frequently people wanted to type up numbers in nicely formatted columns—such as for invoices, where you list items followed by their costs lined up by decimal point with a total at the bottom. (Can you imagine doing that by hand? Congratulations, you just imagined my summer job waaay back when. << Insert Liquid Paper reference here.>>) To make this feasible, someone came up with the TAB key. If you do X on the typewriter, it would remember that “hey, there’s a tab stop here”, and if you hit tab and had not yet reached that column on the row you were typing the print head would jump to that point. How big was it? You guessed it, it depended on what the user needed. (What "X" was totally depended on the typewriter manufacturer.)
Thus and so: no real-world correlation between tabs and spaces, unless there's something obscure from the linotype industry. On typewriters a tab stop would line up with a “regular” character position, whereas on computers there’s no such limitation.
Almost any mature program that involves text implements "double click to select the word" and, in some cases, "triple click to select additional stuff like an entire line" as a feature. I find these features useful but they are often inconsistent between programs.
Example - some programs' double clicks do not select the ending space after a word, but most do. Some recognize the - character as the end of a word, others do not. SO likes to select the entire paragraph as I write this post when I triple click it, VS web developer 2005 has no triple click support, and ultra-edit 32 will select one line upon triple clicking. We could come up with innumerable inconsistencies about how double and triple click pattern matching is implemented across programs.
I am concerned about how to implement this behavior in my program if nobody else has achieved a convention about how the pattern matching should work.
My question is, does a convention (conventions? maybe an MS or Linux convention?) exist that dictates how these features are supposed to behave to the end user? What, if any, are they?
I don’t believe there is a standard to the level of specification you want, and there probably shouldn’t be. Apple Human Interface Guidelines are the most complete. With respect to selecting content (as opposed to controls or discrete data objects), they say:
Double-clicking is most commonly used as a shortcut for other actions, such as… to select a word. Triple-clicking selects the next logical unit, as defined by the application. In a word-processing document, triple-clicking in a word selects the paragraph containing the word…. Double-clicking within a word selects the word. The selection should provide “smart” behavior; if the user deletes the selected word, for example, the space after the word should also be deleted… In some contexts—in a programming language, for example—it may be appropriate to allow users to select both the left and right parentheses (or braces or brackets) in a pair, as well as all the characters between them, by double-clicking either one of them.” (p115-116)
Apple is quite specific about what characters are and aren’t included in a word.
Microsoft’s Windows User Interaction Experience Guidelines say:
For some types of selectable objects, each click expands the effect of the click. For example, single-clicking in a text box sets the input location, double-clicking selects a word, and triple-clicking selects a sentence or paragraph. (p430)
Java Swing Look and Feel Design Guidelines say:
Double-clicking (clicking a mouse button twice in rapid succession without moving the mouse) is used to select larger units (for example, to select a word in a text field)…. Triple-clicking (clicking a mouse button three times in rapid succession without moving the mouse) is used to select even larger units (for instance, to select an entire line in a text field)…. A triple click in a line of text deselects any existing selection and selects the line.
The Gnome Human Interface Guidelines don’t say much about what double- and triple-clicking should do.
This gives you the freedom to choose whatever is best for your users. Double and tripling clicking are expert shortcuts, so their behavior should aim to maximize efficiency. Consider why the user is selecting something and design to make that easiest and fastest.
For example, apparently the rationale behind including the trailing space when double-clicking a word is that users usually select a word in order to copy or paste it in another position in the text. This implies you automatically include the trailing space in order keep the user from having to manually delete a remaining extra space at the source and add a word-separating space at the destination.
Likewise if users are selecting a line of code or paragraph to copy or move it somewhere else, then you probably want to include the newline characters so the user isn’t left with an empty line at the source and force to manually add a newline at the destination (assuming they didn’t want to take the line/paragraph and combine it with another line/paragraph.
If selection is for something other than copying and moving text in sentences, then none of this may apply and you don’t necessarily want to include trailing spaces or newlines. That’s why there shouldn’t be a standard.
An alternative is to do what Apple calls Intelligent Cut and Paste (see the Human Interface Guidelines), or Microsoft Word’s Smart Cut and Paste, where spaces, newlines and other adjustment are algorithmically figured out when cutting, copying, pasting, and deleting, not when selecting.
In my perfect world I would have it work like this.
Double click on a word selects the word only (a word according to the grammar rules of the locale), no trailing space (this is for easier copying between programs so that I would not need to remove any spaces when pasting)
If I remove the selected word my text editor is aware of my content and removes any additional spaces left over
A triple click selects a line with no trailing newlines. (A paragraph is a long line that has been wrapped)
In Windows, Linux and OS X double-click selects the word under cursor triple-click selects the entire line of text (single line only, i.e., wrapped line)
Finding answers and come up with a alternative solution:
I like to write code or command in text, and copy them to shell prompt without the ending \n
1. use notepad
2. surround each line with ()
3. use ctrl + double click.
Fine...
I need to turn automatic margins off according the following statement from Screen's manual in my Mac
If your terminal is a "true"
auto-margin terminal (it doesn't allow
the last position on the screen
to be updated without scrolling the screen) consider using a version
of your terminal's termcap that
has automatic margins turned off.
How can you turn automatic margins off by your terminal's termcap?
Most terminal emulators, including the mac default terminal, are not "true auto-margin terminals" in the sense being discussed here - they emulate a vt100-series terminal, which had "smart" wraparound. You can check by running cat and typing to the end of the last line - after you type the last character, the cursor remains at the end of the line (highlighting the character you just typed) until you type another character.
The only consequence of a 'true auto-margin terminal' is that a character cannot be displayed in the lower right hand corner (though some programs are able to work around that by shifting a character into place with ich/ich1)
According to XTerm Control Sequences, this sequence should do what was asked:
CSI ? 7 l
That is,
printf '\033[?7l'
The 7 is documented as
Ps = 7 -> Wraparound Mode (DECAWM).
and the final character l (lowercase L) denotes this as a reset rather than a set control.
For whatever reason, the terminfo name for this is more obscure: "automatic margins". These terminfo capabilities deal with the feature (see terminfo(5)):
auto_right_margin am am terminal has auto‐
matic margins
enter_am_mode smam SA turn on automatic
margins
exit_am_mode rmam RA turn off automatic
margins
Interestingly, the vt100-nam terminal description in ncurses (which apparently no one uses) initializes the terminal to use automargins margins using this string:
rs2=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h,
(the \E[?7h sets it), and asserts that the terminal does not use automatic margins by cancelling am. It also has the terminfo capabilities rmam and smam. So you could do this to prove that it works:
tput rmam
stty columns 999
ps -efwwwwwl
and (for the ordinary user) see the ps listing nicely truncated against the right margin of the terminal window.
The other variants vt220-nam and vt320-nam appear correct...
By the way, for Mac, you would use the terminfo names such as rmcup rather than the termcap RA, because OSX uses ncurses' tput (terminfo) rather than the BSD variant.
Further reading:
tput, reset - initialize a terminal or query terminfo
database
history section for tput
history section for tset
Occasionally someone asks about suppressing automargins because they suppose that terminals can pan/scroll left/right to show the information which was not wrapped to a new line. Terminals which do this are rare, and OSX Terminal is not one of those. It behaves like a subset of xterm, which itself emulates the series of DEC terminals vt52/vt100/vt220/etc. In this question, OP is concerned/confused about this paragraph from the screen manual:
If your terminal is a "true" auto-margin terminal (it doesn't allow the
last position on the screen to be updated without scrolling the screen)
consider using a version of your terminal's termcap that has automatic
margins turned off. This will ensure an accurate and optimal update of
the screen in all circumstances. Most terminals nowadays have "magic"
margins (automatic margins plus usable last column). This is the VT100
style type and perfectly suited for screen. If all you've got is a
"true" auto-margin terminal screen will be content to use it, but
updating a character put into the last position on the screen may not
be possible until the screen scrolls or the character is moved into a
safe position in some other way. This delay can be shortened by using a
terminal with insert-character capability.
That last position on the screen refers to the lower-right corner of the terminal. In the normal case, if your cursor is on the lower-right corner and you print a character, you would expect the display to scroll up by one line and show the character on the next line. Also (because terminals can be implemented in different ways), some could scroll up when you print a character in the last position. The VT100 does not do this. Not only does it not scroll up in that case, but it ignores non-printing characters while on the margin (see xterm FAQ That description of wrapping is odd, say more?). There is a terminfo flag xenl which is set to show when the terminal does this special behavior. About a third of the terminal descriptions in the terminal database have this flag. While most of those are for terminals which you likely will never encounter, keep in mind that the advice in the manual page was written back in an era when those other terminals were as likely to be found as a VT100-lookalike. The early change-history for screen is poor, but the text was in screen's second posting to Usenet in 1992. The initial posting in 1987 said something similar:
Screen
never writes in the last position of the screen, unless the boolean
capability LP is found in the termcap entry of the terminal.
Usually,
screen
cannot predict whether or not a particular terminal scrolls when
a character is written in the last column of the last line;
LP indicates that it is safe to write in this position.
Note that the LP capability is independent of am (automatic
margins); for certain terminals, such as the VT100, it is reasonable
to set am as well as LP in the corresponding termcap entry
(the VT100 does not move the cursor when a character is written in
the last column of each line).
The later wording reflects the fact that the terminfo system was prevalent, and the name LP was not termcap name chosen for corresponding with xenl (it is xn).
The point of all of this is that screen attempts to convert between programs writing to different terminal types and make them all appear like one type of terminal — which means that it tries to put text on the terminal's display in all of the locations. The lower-right corner is a problem because some terminals would scroll up, spoiling the attempt to write there. As a workaround, some terminals provided an alternative:
using a different mode (insert),
put the cursor on the next to last position of the display,
write characters to fill in, pushing a character into the last position, and
turn insert-mode off once it is done (otherwise a nuisance).
About two thirds of the descriptions in the terminal database have the capability to do this insert-mode (smir). That still was not perfect, but it certainly was worth mentioning in 1992. About a quarter implement a similar similar feature ich1. Some implement both (and vi could get confused by those, by trying to do both methods).
VT100-lookalikes provide a third way to write that last position; screen checks for and uses whatever is there.
If I understand you correctly you're looking to set the autowrap feature to NO using terminfo database. If so I believe you can use the -nam flag to turn it off - something like vt100-nam should do it. You can also check by looking at the man pages for terminfo.
If this solves your question, mark this up. (^_^) If not... well comment back and I'll check again for you. Cheers!
Update: There's also a shortcut that may apply to you to toggle the wrap off and on. Check out the shortcut sheet here. And additional information for Screen can be found here (search for wrap). You can also check here on how to use setterm (section 17.14 Changing the Terminal Settings). Also check here for examples of changing settings.
Good luck again. (^_^)
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)