^M is the dos carriage return that's left after each line when you move a file from a Windows box to a *NIX box. I know how to remove it. I am curious to know is there any other reason besides aesthetics that it should be removed from a PHP script.
The PHP script runs fine with it in. Normally, I would remove it without hesitation, but don't want to have my name next to each line in an svn blame command. (besides the point).
Question: Is there a reason in regards to functionality of why it should be remove other than aesthetics? It doesn't seem to break anything to keep it in. (Give me a good reason plz)
All in all, it should be fine. Other languages are picky about their line endings; I've seen it cause issues in Perl scripts, for example. But for PHP, i've never seen it matter much.
One occasion where it could conceivably matter is in multi-line strings, where the extra chars would make it through to the output. This might matter if your output is not HTML or XML. But JS shouldn't be particular about extraneous CRs, and HTML and XML will generally treat any whitespace the same as a single space (or in many cases, disregard whitespace altogether). Textareas and <pre> elements and such might end up with extra whitespace in them. That's about the only issue i can think of.
Related
I have a .html file that is working perfectly fine but for some reason Sublime 3 decides that it has invalid code, check the image below:
Any idea why that's happening and how to fix it without having to modify the code?
The HTML5 spec states (my emphasis):
Comments must start with the four character sequence U+003C LESS-THAN SIGN, U+0021 EXCLAMATION MARK, U+002D HYPHEN-MINUS, U+002D HYPHEN-MINUS (<!--). Following this sequence, the comment may have text, with the additional restriction that the text must not start with a single > (U+003E) character, nor start with a U+002D HYPHEN-MINUS character (-) followed by a > (U+003E) character,
nor contain two consecutive U+002D HYPHEN-MINUS characters (--),
nor end with a U+002D HYPHEN-MINUS character (-). Finally, the comment must be ended by the three character sequence U+002D HYPHEN-MINUS, U+002D HYPHEN-MINUS, U+003E GREATER-THAN SIGN (-->).
So that's why it's complaining. As to how to fix it without changing the code, that's trickier.
Your contention that it works is no different really to C developers wondering why they need to worry about undefined behaviour because the code they wrote works fine. The fact that it works fine in one particular implementation is not relevant to portable code.
My advice is to actually change the code. It's not valid, after all, and any browser (current or future) would be well within its rights to simply reject it.
As an aside after some historical digging, it appears this is not allowed because SGML, on which HTML was based, had slightly different rules regarding comment.
On sensing the <!-- token, the parser was switched to a comment mode where > characters were actually allowed within the comment. If the -- sequence was encountered, it changed to a different mode where the > would end the comment.
In fact, it appears to have been a toggle switch between those two modes, so something like <!-- >>>>> -- xyzzy -- >>>>> --> was possible, but putting a > where the xyzzy would end the comment.
XML, for one, didn't adopt this behaviour and HTML has now modified it to follow the "don't use -- within comments at all" rule, the reason being that hardly anyone knew that the comments behaved in the SGML way, causing some pain :-)
Is there any way using either Vim scripting or search/replace to remove ghost newlines? I have come across times when I have to edit files that other developers using crappy software have left double newlines in like the attached picture.
I would love to find a way in Vim to remove all those stupid double spacing junk so it actually looks like it should.
Running the search-and-replace
%s/\n\n/\r/g
will replace every pair of two newlines with a single one. This will inevitably screw up files that aren't already double-spaced, though, so don't use it blindly.
Shorter solution:
:v:.:d
It those lines are really empty. If there might be white spaces:
:v:^\S*$:d
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.
The current project I'm working requires me to follow certain procedures to eliminate whitespace in my code. Apparently this has got something to do with line endings since one requirement explicitly tells me to "end all lines with a Unix line ending (\n)".
I code in VIM from the terminal, and I press enter for a new line to write on. Am I missing something here?
What is the reason to keep the code clean from trailing whitespace and using specific types of line breaks?
On a side note, what standard VI/VIM settings do you guys use to adhere to common coding standards?
Sincerely,
Why
Different operating systems have different line break conventions. Unix-like systems prefer \n (LF); Windows prefers \r\n (CR LF); pre-OSX Mac OS used \r (CR). Maintaining one convention across a project is usually a good idea.
As for trailing whitespace, AFAIK it's just sloppy (may indicate "quick and dirty" reformatting). In some environments trailing whitespace might also be significant.
Perhaps not everyone on the project codes in VIM, they might be using a windows based IDE which would insert \r\n for a new line.
They would have to ensure that their line-endings are correct before committing code, whereas you shouldn't have this problem as vim will use \n as its natural line ending.
To enforce this in vim, you can use the fileformat option. Setting it to unix will make your newlines use \n.
The answer to this must be somewhere but I'm not finding it -- can anyone help me understand why in Gedit, if I have a page of code there is no extra trailing blank line, but then when I do a file comparison for my svn commit it shows an extra line being added at the end of the file?
I have a feeling that Gedit is automatically adding an ending line break. But why, I have no idea...
Reality finally won and it's been fixed, but the broken behavior is still the default; enable the WYSIWYG behavior in a terminal with
gsettings set org.gnome.gedit.preferences.editor ensure-trailing-newline false
It's a feature. I don't think it can easily be disabled.
this is intentional: text files should always be terminated by \n, otherwise
tools like 'cat', 'sed' etc may have problems. However there is no reason to
always show an empty line at the bottom of the text view, that's why we do not
show the last \n
paolo borelli [gedit developer]
Some editors (I'm unfamiliar with Gedit specifically) will try to ensure that a file always ends with a newline character. Other editors, like perhaps the one that you originally created the file with, will allow you to end a file without a final newline character.
Try the Whitespace Remover plugin.