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.
Related
I have written some c code, and the end of my output is '\n', when I check the output text file in vim, I cannot find the last empty line, however, when I open it with another text viewer, I can find the last empty line. How can I configure my vim to show the empty line?
The way Vim shows \n / 0x0a at the end of the file is that it opens the file without complaining about [noeol] when :editing the file (in a kind of "reverse logic" from what you expect). Vim's (and Unix) philosophy is that the trailing newline should be there. This can be confusing when one is used to other editors or predominantly works on MS Windows.
There's a lot of discussion and questions about this (e.g. here); as this is unlikely to change, get used to it.
So oftentimes, while editing with Vim, I'll get into a variety of situations where whitespace gives me hassle. For example, say I have a comment like this:
#This program was featured on the Today show, it is an algorithm for promoting world peace in third-world countries
#given the name of that country and the name of a celebrity to endorse its cause
If I want to, for example, trim the lines so they go to X characters, I end up putting a newline somewhere in the middle of the top line to get this (after hitting the newline and auto-indenting):
#This program was featured on the Today show, it is an algorithm for promoting
world peace in third-world countries
#given the name of that country and the name of a celebrity to endorse its cause
I then add a # to the beginning of the line, and that's all well and good, but then I want that line to line up, too. To do so, I have to delete the newline, all the whitespace for the indent on the next line, and then the commenting # mark. It doesn't take an awfully long amount of time to do that, but this and similar situations all add up over a day's worth of coding.
Now the example above is pretty specific, but my question isn't. What's a good way in Vim to delete all whitespace INCLUDING NEWLINES up until the next non-whitespace character? If Vim already has movements that do that, that would be awesome, but if not, does anyone have a favorite Vim function they use to do the above that could be mapped to a key? At the very least, am I missing some Vim usage idiom that prevents me from even having to worry about this case?
EDIT: Formatting to width, while useful and applicable to the case above, isn't the focus of this question. I'm concerned more with whitespace removal that doesn't stop at the end of a line, but instead carries on to the first non-whitespace character of the next line.
You really just want to reformat that comment to fit the current 'textwidth'. If the comment is a paragraph (i.e., separated by a line of whitespace above and below), then you can just use gqip (gq is the reformat command, ip is the "inner-paragraph" text object) to reformat it. If it's not a standalone paragraph, you can visually select those lines and then use gq.
This likely also relies on having 'formatoptions' set correctly to make sure the comment characters are handled properly, but in many cases the ftplugin has already done that.
This is a while later, but I found that there is a command that does what I need to in 90% of circumstances:
J -- join line below to the current one
This command seems to work:
:.s/\W*$\n\W*//g
it uses a replace to remove whitespace up to end of line and the new line at the end.
In this example:
testting aad $
asdjkasdjsdaksddjk$
(to see meta characters in vim use the command :set list)
if you place the cursor on the first line and use the first command it will delete everything from aad to $ (not including aad but including $ and a newline.)
Also, note for what you are doing it is far more efficient to use an external program to format comments for you. In particular, par is a great small C program that edits text and wraps it to desired lengths.
If you have par in your path, to do what you are trying to do is as easy as selecting the block of comment with Shift+v and running the command
:!par 40pgr
where 40 is the desired width in columns.
If you are feeling hackish, write your own program in C/perl/C++/python that edits comments however you like, then put it in path and use the external filter command :! to process blocks of text through it.
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.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Why did we bother with line numbers at all?
I'm curious about why early versions of the BASIC programming language had line numbering like in:
42 PRINT "Hello world!"
The text editors back then had no line numbering?
EDIT: Yes, I know they are used for GOTOs, but why? I mean having labels was too computationally expensive?
Many microcomputers had a BASIC interpreter in ROM that would start upon bootup. The problem was that there was no text editor or file system to speak of. You had an interactive prompt to do everything through. If you wanted to insert a line of code, you just typed it, starting with the line number. It would insert it into the correct spot in you code. e.g:
>10 print "hello"
>30 goto 10
>20 print "world"
>list
10 PRINT "hello"
20 PRINT "world"
30 GOTO 10
>
(In that example > is the BASIC prompt)
If you wanted to erase a line, you would type something like ERASE 20.
Some really fancy systems gave you a line editor (i.e. EDIT 10)
And if you didn't plan your line numbers and ran out (how do I insert a line between 10 and 11?) some systems gave you a RENUM command which would renumber your code (and adjust GOTOs and GOSUBs appropriately).
Fun Times!
The original BASIC line numbering was actually an integral part of the language, and used for control flow.
The GOTO and GOSUB commands would take the line, and use it for control flow. This was common then (even though it's discouraged now).
They were used as labels for GOTO and GOSUB
Like this:
10 PRINT "HELLO WORLD"
20 GOTO 10
There were no named labels in some early BASIC versions
They were also required if you wanted to insert a line between 2 existing lines of code, because in the early days, you had no full text editors. Everything had to be typed in the "interactive" interpreter.
So if you typed:
15 PRINT "AND THE UNIVERSE"
The program would become:
10 PRINT "HELLO WORLD"
15 PRINT "AND THE UNIVERSE"
20 GOTO 10
When you ran out of line numbers, you could run a "renumbering" tool to renumber all lines in your program, but in the very early days of the Commodore 64 and other home computers, we didn't even have that, so you'd have to renumber manually. That's why you had to leave gaps of 10 or more in the line numbers, so you could easily add lines in between.
If you want to try out the Commodore 64 interpreter, check out this C64 emulator written in Flash: http://codeazur.com.br/stuff/fc64_final/ (no install required)
In BASIC, the line numbers indicated sequence.
Also, many older editors weren't for files, but simply lines ("line editors", e.g. ed, the standard editor). By numbering them this way, you knew which line you were working on.
A simple google reveals what wikipedia has to say about it:
Line numbers were a required element of syntax in some older programming languages such as GW-BASIC.[2] The primary reason for this is that most operating systems at the time lacked interactive text editors; since the programmer's interface was usually limited to a line editor, line numbers provided a mechanism by which specific lines in the source code could be referenced for editing, and by which the programmer could insert a new line at a specific point. Line numbers also provided a convenient means of distinguishing between code to be entered into the program and commands to be executed immediately when entered by the user (which do not have line numbers).
Back in the day all languages had sequence numbers, everything was on punched cards.
There was one line per card.
Decks of cards made up your program.
When you dropped the cards, you'd put them in a card sorter that used those sequence numbers.
And of course, they were referenced by control flow constructs.
On the C64, there wasn't even a real editor (built-in at least). To edit a part of the program, you'd do something like LIST 100-200, and then you'd only be able to edit those lines that were currently displayed on the screen (no scrolling upwards!)
They were labels for statements, so that you could GOTO the line number. The number of the statements did not necessarily have to match the physical line numbers in the file.
The line numbers were used in control flow. There were no named subroutines. You had to use GOSUB 60, for instance, to call the subroutine starting at line 60.
On your update, not all languages had labels, but all languages had line numbers at one time. At one time, everything was punch cards. BASIC was one of the very first interactive languages, where you could actually type something and have a response immediately. Line numbers were still the current technology.
Labels are an extra expense. You have to keep track of the correlation between the symbolic label and the code or data to which it refers. But if every line has a line number (and if all transfer of control flow statements always refer to the beginning of a line), then you don't need a separate symbol table.
Also keep in mind that original BASIC interpreters didn't need a symbol table for variables: There were 26 variables named A-Z. Some were sophisticated and had An-Zn. Some got very fancy and added a distinction between string, integer and floating point by adding "$" or "%" after the variable. But no symbol table was required.
IIRC, line numbers were mostly used as labels for GOTO and GOSUB statements, since in some (most?) flavors of BASIC there was no way to label a section of code.
They were also used by the editor - ie you said:
edit 100
to edit line 100.
As others have pointed out, these line numbers were used as part of subroutines.
Of course, there's a reason that this isn't done anymore. Imagine if you say GOTO 20 on line 10, and then later realize you need to write 10 more lines of code after line 10. All of a sudden, you're smashing up against 20 so you either need to shift your subroutine farther away (higher numbers) and change your GOTO value, or you need to write another subroutine that jumps farther in the code.
In other words, it became a nightmare of true spaghetti code and is not fun to maintain.
It was entered in on the command-line in many instances (or was, on my old Commodore 64) so there might not always have been a text editor, or if there was, it was quite basic.
In addition, you would need to do GOTOs and the like, as well as inserting lines in between others.
ie:
10 PRINT "HELLO"
20 GOTO 10
15 PRINT " WORLD"
where it would go in the logical 10 15 20
Some editors only had an "overwrite" mode and no "insert" mode. This made editing of existing code extremely painful. By adding that line-number feature, you could however patch existing code from anywhere within the file:
100 PRINT "Broken Code"
200 PRINT "Foobar"
...
101 patch the broken code
102 patch more broken code
Because line numbers didn't have to be ordered within the file.
Line numbers were a PART of the language, in some VERY early ones, even the OS was just these simple lines. ALL you had was one line at a time to manipulate. Try writing an accounting system using 1-4k program files and segmenting it by size to get stuff done. To edit you used the line numbers to tell what you were editing. So, if you entered like:
10 PRINT "howdy"
20 GOTO 10
10 PRINT "WOOPS"
15 PRINT "MORE WOOPS"
20
RUN
YOU WOULD GET:
WOOPS
MORE WHOOPS
The blank 20 would effectivly delete that line.
When I open a text file in Notepad, it shows a blank line if there is a carriage return at the end of the last line containing text. However, in Vim it does not show this blank line. Another thing I've noticed is that the Vim editor adds a carriage return to the last line by default (even though it doesn't show it). I can tell, because if I open a file in Notepad that was created in Vim, it shows a blank line at the end of the file.
Anyway, I can live with these two differences, but I'm wondering if there is an option in Vim that allows you to toggle this behaviour.
Thanks
PS - GVim 7.2
[Update]
Would this make sense to be on Server Fault instead?
[Update 2]
I'll rephrase this... I need to know when there is a carriage return at the end of single line file (Notepad shows an extra line with no text, with Vim I cannot tell). This is due to a Progress program that reads a text file (expects a single line, but with a carriage return) and parses the text for some purpose. If there is no carriage return, Progress treats the line as if it is null.
[Workaround Solution]
One way I've found to ensure there is a carriage return (but make sure I don't add a second one) is to make sure I have the end of line write option turned on (:set eol) and then just do a write/save. This will put an end of line in the file if it's not already there. Otherwise, it doesn't add a new one.
:help endofline
explains how you could stop vim from adding an extra newline.
It seems that vim treats newline as a line terminator, while notepad treats it as a line separator: from http://en.wikipedia.org/wiki/Newline
There is also some confusion whether
newlines terminate or separate lines.
If a newline is considered a
separator, there will be no newline
after the last line of a file. The
general convention on most systems is
to add a newline even after the last
line, i.e., to treat newline as a line
terminator. Some programs have
problems processing the last line of a
file if it isn't newline terminated.
Conversely, programs that expect
newline to be used as a separator will
interpret a final newline as starting
a new (empty) line. This can result in
a different line count being reported
for the file, but is otherwise
generally harmless.
If I recall correctly, on unix-y systems a text file must be terminated with a newline.
One useful Vim option is
set list
It will help you see all end of lines characters (and possibly other generally invisible chars). So you will be able to view this last endofline directly in Vim and not only in Notepad.
When you open the file in VIM the status line should say [noeol] after the filename. So that's one indication. As Manni said, you can change this by setting both the endofline option off and the binary option on. You can set this as your default settings in a .vimrc file.