If there are two keywords then they must have their own meanings. So I want to know what makes them different and what their code is.
A line feed means moving one line forward. The code is \n.A carriage return means moving the cursor to the beginning of the line. The code is \r.
Windows editors often still use the combination of both as \r\n in text files. Unix uses mostly only the \n.
The separation comes from typewriter times, when you turned the wheel to move the paper to change the line and moved the carriage to restart typing on the beginning of a line. This was two steps.
In very layman language Enter key press is combination of carriage return and line feed.
Carriage return points the cursor to the beginning of the line horizontally and Line feed shifts the cursor to the next line vertically. Combination of both gives you the new line (\n) effect.
Reference: https://en.wikipedia.org/wiki/Carriage_return#Computers
Both of these are primary from the old printing days.
Carriage return is from the days of the teletype printers/old typewriters, where literally the carriage would return to the next line, and push the paper up. This is what we now call \r.
Line feed LF signals the end of the line, it signals that the line has ended - but doesn't move the cursor to the next line. In other words, it doesn't "return" the cursor/printer head to the next line.
For more sundry details, the mighty Wikipedia to the rescue.
Both "line feed' (0x0A or 10) and 'carriage return' (0x0D or 13) are single-byte values. These values are the accepted standard for LF/CR. Most languages will type these as 'characters.' You can find these values on any standard ASCII table.
For example, in C# a string such as:
String str = "\n\r";
is two characters long (ignoring the hidden end null character '0x00' required in string types). However, you could make an equivalent array of type character such as:
char[] c = new char[](){0x0A,0x0D}; // LF, CR
Related
Why people on VStudio with norminette highlights put an empty line at end.
And when they do norminette in iTerm it’s Works
When you use Vim and put an empty line at end the norminette say Error extra line.
This happen yesterday and today my Vstdio ask for a line at end and when I do norminette in iTerm it’s say error extra line. I go back to vim, delete the line and norminette say error again to remove extra line. I need to open back the file, add line and then delete and save to have norminette working. So now sometime moulinette say KO on server but OK my side. I need to add/remove last line every time with vim when I work on vstdio
So if someone know the issue i would like to have a better solution than double check on vim for the next 3 week and maybe 3 years 🤣 thx all!
That topic has already been discussed to death.
No matter what system you are on, lines in text files generally end with one or two invisible characters. On some systems, it's a "carriage return" CR followed by a "line feed" LF, on other systems it's only a CR, on other systems it's only a LF, and that's only for the least exotic ones. That character or pair of characters has a few colloquial names: "newline", "EOL", etc. I will use "EOL" from now on.
Now, EOL has two semantic interpretations. In some contexts, EOL is considered to be a "line terminator", meaning that no assumption is made about what comes after it, and in some other contexts, EOL is considered to be a "line separator", meaning that there is always a line after it.
And then there is the related problem of how a stream of text should end. With the first interpretation, the last line of a stream should end with EOL, if only to be able to establish a boundary between two streams. With the second interpretation above, the last line of a stream shouldn't end with EOL because it would mean… that the last line is not really the last line.
So, basically, this text:
foo
bar
baz
could be encoded as (first interpretation):
foo<EOL>
bar<EOL>
baz<EOL>
or as (second interpretation):
foo<EOL>
bar<EOL>
baz
Most Unix-like tools have adopted the first interpretation for decades and generally expect EOL on the last line but many more modern tools have adopted the second interpretation, which leads to much confusion among new generations who juggle between GUI editors and CLI tools.
Feed some text with a final EOL to a tool that interprets it as a "line separator" and you get an imaginary line displayed at the end of the file:
1 foo
2 bar
3 baz
4
Feed some text without a final EOL to a tool that interprets it as "line terminator" and you can get anything from a reasonable display (as follows) to loud complaints (git):
1 foo
2 bar
3 baz
Add to that confusing names like "newline" and you have a recipe for a never-ending stream of questions like this one.
So… this is what seems to be going on, here:
you are using a mix of tools that interpret EOL differently,
you are interpreting one of those interpretations incorrectly,
and you act upon that misinterpretation, with confusing results.
Let's address these one-by-one.
Well, we all do so ¯\_(ツ)_/¯.
What appears like an extra line at the bottom of your file in a modern GUI editor is unlikely to be an extra line. It is more likely to be an artefact of the second interpretation. Assuming you are on some kind of Unix-like system and the expected EOL is LF, you can do $ xxd filename to inspect its content in hexadecimal form:
a single a0 at the end means that your file ends with EOL,
a a0a0 at the end means that your file has an extra empty line,
no a0 at the end means that it was written by a an editor that firmly adheres to the second interpretation.
The second case will angry your linter:
Error: EMPTY_LINE_EOF (line: 7, col: 1): Empty line at end of file
but it doesn't seem to particularly care about the other two cases.
Because you see what appears to be an empty line at the end of a file in a GUI editor it doesn't mean that a) that line actually exists and b) that you must add one at the end of the file in Vim or any other editor.
The correct approach is to:
let Vim do what it does out the box, write files with an EOL at the end, because that's what your toolchain (including Norminette) expects,
set up your GUI editors to do the same (even if they still show that imaginary line),
get rid of any extraneous empty line you might have in one of your projects,
NEVER add an extraneous empty line at the end of your files, as it useless at best and forbidden at worst.
Say I have a line that looks like this:
(Type)obj.method());
Is there a motion that will go to the last of a specific character on a line? I'd like to do
^c (motion to ')' character) (insert text) <Esc>
and transform that line to
obj.otherMethod());
I know I can use #f or #t, but I'd rather not count the parens.
As I understand your question, you don't just want to go to the last instance of a character, which you could achieve by going to the end of the line and searching backward. You want to clear text from your current caret position to the last instance of a character, right?
I'd typically use a pattern search to complete a motion to a desired character when there may be n of the same character in between. In your example, you can clear from the current caret position to the last ) by using c/);Enter, since only the last instance of o is followed by ;. You could precede this with a v instead of c, for example, if you wanted to select everything in between.
Using the same example, you could move to the 3rd o with /odEnter.
It may seem tedious at first, but in practice you are probably looking directly at the spot where you want be, so you can already see the additional characters you need and you only need to increase you specificity until you get the match, and you'll have immediate visual feedback as long as you have set incsearch.
Note: If your line did not have a semicolon at the end, you could move to the last paren by using )\n to search for the next ) followed by a line break.
You could use visual mode:
v$F)c
But in this case you're really just inserting some new text and changing the case:
f.aotherEscl~
What are the differences among Carriage Return, Line Feed and New line? Does it depend on OS? Why do we need to use all of them just for getting to next line?
Generally, a "new line" refers to any set of characters that is commonly interpreted as signaling a new line, which can include:
CR LF on DOS/Windows
CR on older Macs
LF on Unix variants, including modern Macs
CR is the Carriage Return ASCII character (Code 0x0D), usually represented as \r.
LF is the Line Feed character (Code 0x0A), usually represented as \n.
Original typewriter-based computers needed both of these characters, which do exactly what they say: CR returned the carriage to the left side of the paper, LF fed it through by one line. Windows kept this sequence unmodified, while Unix variants opted for more efficient character usage once they were only needed symbolically.
Make sure you look for a platform-agnostic new line symbol or function if you need to represent this sequence in code. If not, at least make sure that you account for the above three variants.
More on the history: The Great Newline Schism - Coding Horror
I have the following characters being repeated at the end of every line:
^[[00m
How can I remove them from each line using the Vim editor?
When I give the command :%s/^[[00m//g, it doesn't work.
You could use :%s/.\{6}$// to literally delete 6 characters off the end of each line.
The : starts ex mode which lets you execute a command. % is a range that specifies that this command should operate on the whole file. The s stands for substitute and is followed by a pattern and replace string in the format s/pattern/replacement/. Our pattern in this case is .\{6}$ which means match any character (.) exactly 6 times (\{6}) followed by the end of the line ($) and replace it with our replacement string, which is nothing. Therefore, as I said above, this matches the last 6 characters of every line and replaces them with nothing.
I would use the global command.
Try this:
:g/$/norm $xxxxxx
or even:
:g/$/norm $5Xx
I think the key to this problem is to keep it generic and not specific to the characters you are trying to delete. That way the technique you learn will be applicable to many other situations.
Assuming this is an ANSI escape sequence, the ^[ stands for a single <Esc> character. You have to enter it by pressing Ctrl + V (or Ctrl + Q) on many Windows Vim installations), followed by Esc. Notice how this is then highlighted in a slightly different color, too.
It's easy enough to replace the last six characters of every line being agnostic to what those characters are, but it leaves considerable room for error so I wouldn't recommend it. Also, if ^[ is an escape character, you're really looking for five characters.
Escape code
Using ga on the character ^[ you can determine whether it's an escape code, in which case the status bar would display
<^[> 27, Hex 1b, Octal 033
Assuming it is, you can replace everything using
:%s/\%x1b\[00m$//gc
With \%x1b coming from the hex value above. Note also that you have to escape the bracket ([) because it's a reserved character in Vim regex. $ makes sure it occurs at the end of a line, and the /gc flags will make it global and confirm each replacement (you can press a to replace all).
Not escape code
It's a simple matter of escaping then. You can use either of the two below:
:%s/\^\[\[00m$//gc
:%s/\V^[[00m\$//gc
If they are all aligning, you can do a visual-block selection and delete it then.
Otherwise, if you have a sequence unknown how to input, you can visually select it by pressing v, then mark and yank it y (per default into register "). Then you type :%s/<C-R>"//g to delete it.
Note:
<C-R>" puts the content of register " at the cursor position.
If you yanked it into another register, say "ay (yank to register a - the piglatin yank, as I call it) and forgot where you put it, you can look at the contents of your registers with :reg.
<C-R> is Vim speak for Ctrl+R
This seems to work fine when the line is more than 5 chars long:
:perldo $_ = substr $_, 0, -5
but when the line is 5 or less chars long it does nothing.
Maybe there is a easy way in perl to delete the last 5 chars of a string, but I don't really know it:)
Use this to delete:
:%s/^[[00m//gc
Is it possible to have a carriage return without bringing about a linebreak ?
For instance I want to write the following sentences in 2 lines and not 4 (and I do not want to type spaces of course) :
On a ship at sea: a tempestuous noise of thunder and lightning heard.
Enter a Master and a Boatswain
Master : Boatswain!
Boatswain : Here, master: what cheer?
Thanks in advance for your help
Thierry
In a text file, the expected line-end character or character sequence is platform dependent. On Windows, the sequence "carriage return (CR, \r) + line feed (LF, \n)" is used, while Unix systems use newline only (LF \n). Macintoshes traditionally used \r only, but these days on OS X I see them dealing with just about any version. Text editors on any system are often able to support all three versions, and to convert between them.
For VIM, see this article for tips how to convert/set line end character sequences.
However, I'm not exactly sure what advantage the change would have for you: Whichever sequence or character you use, it is just the marker for the end of the line (so there should be one of these, at the end of the first line and you'd have a 2 line text file in any event). However, if your application expects a certain character, you can either change the application -- many programming languages support some form of "universal" newline -- or change the data.
Just in case this is what you're looking for:
:set wrap
:set linebreak
The first tells vim to wrap long lines, and the second tells it to only break lines at word breaks, instead of in the middle of words when it reaches the window size.