I am using emmet with Coda 2, version 2.6.6. When I use it to create multiple lines, Coda is showing some sort of end of line character.
For instance, if I use section.container>div*4>{$}, I get the following:
At the end of the first three divs is a some sort of EOL character, and I don't know how to get rid of it. I looked through the editor preferences and did not see anything that would allow me to hide that character. I've tried it on two different macs and have the exact same results.
Is there a way to get rid of it.
I've noticed this recently in 2.5.16. it may be related to having mixed line endings.
If you go to Text > Line Endings > Convert to (whatever type of line endings you use), it should clear the symbol.
Related
Informix 11.5
I am trying to search for carriage returns and line feeds that may exist in a VARCHAR field. First, I need a SELECT statement to show that they exist. Second, I need to REPLACE them with a space or other character.
I've tried all kinds of variations:
CHR(10) + CHR(13)
CHR(10) || CHR(13)
CHAR(13) + CHAR(10)
CHAR(13) || CHAR(10)
SELECT CHR(10) from systables;
Everything gives an error: Routine (chr) can not be resolved.
I've been searching all over and just can't find anything that works, and I'm sure this is crazy stupid easy.
Get the ASCII package from the IIUG
The CHR() function was added to IDS 11.70; it isn't in IDS 11.50.
The good news is you can add the function because IDS is an extensible server. The better news for you is that you can obtain the relevant code from the IIUG web site in the Software Archive under the Miscellaneous section as ascii.
That should allow you to do what you need. (Note: I wrote the code way back when — before there was support built into any of the servers.)
Windows makes things more complicated
I was uploading the ascii.unl file and I get an error that the number of columns do not match on line 13. Have you seen this before? I'm on Windows 2008. The errors are:
846: Number of values in load file is not equal to number of columns.
847: Error in load file line 13.
I hadn't seen it before, but I've not tried the file on Windows and … well, let's say life gets trickier on Windows than it is on Unix (and this bit isn't all that simple on Unix).
First of all, the data file needs to have CRLF line endings instead of the NL-only line endings that are standard on Unix. (Note that NL, newline, is another name for LF, line feed — aka '\n'.) For most lines in the unload file, that isn't a problem.
The two entries for which it might be (is) a problem are for CR and LF — entries 13 and 10 respectively. In theory, if the entry for line 10 contains (in C string notation) "10|\\\n\r\n" (that is, 10, pipe, backslash, newline, CRLF), all should be OK; the absence of an error message for line 10 suggests that it is OK.
Similarly, the entry for line 13 is "13|\r\r\n", which apparently causes grief. The simplest trial fix is to add a backslash here too: "13|\\\r\r\nn". The backslash says "the next character doesn't have a special meaning". If that doesn't work, we'll probably have to try hex-escape notation: "13|\\0d\r\n" — and use dbaccess -X to enable the hex escape notation.
With luck, one of those two (or both) will work. If neither works, come back and we'll try to think of something else.
As per my above comment:
I was uploading the ascii.unl file and I get an error that the number of columns do not match on line 13. Have you seen this before? I'm on Windows 2008. 846: Number of values in load file is not equal to number of columns. 847: Error in load file line 13.
Here is what I see in the ascii.unl file.
If I put this into MS Word and turn on Show Formatting/Paragraph marks, it shows this:
I have a text file which shows a Line Break in UltraEdit if we replace a special character in text file manually it works fine. Unknown Line Break. I have to change it manually and then process the files.
Please let me know some way how to remove all occurrences of this character with VB.Net code.
If I replace ♀ in UltraEdit, it replaces line break with my desired string. But in my VB string I cannot use this character or line break.
The character you have in your file is the form-feed character usually used as control character for a page break.
In UltraEdit in Page Setup configuration dialog (a printing related dialog) there is the option Page break code which has by default the decimal value 12 (hexadecimal 0C) which is the form-feed character.
A page break can be displayed in UltraEdit with a horizontal line across the document window on enabling Show Page Breaks as Lines in menu/ribbon View.
The form-feed character can be removed in UltraEdit with searching for ^b on using a normal, non regular expression or an UltraEdit regular expression replace, or with searching for \f on using a Unix or Perl regular expression replace.
In VB.Net code ChrW(12) can be used to reference the form-feed control character as suggested already by Hans Passant.
I have an SQL export file from my server with comments. The line comment operator used was the hashtag #. Notepad++ does not treat this like a commented out line, as in, the color does not change and any words such as like and while are changed to bold blue.
When you run the script on the server to install the SQL, it runs fine, the comments are treated as they should be. How do you tell NPP that the # operator is supposed to comment out the line? Both show the color and have Ctrl-k add a # in front of the line.
Note: I added commentLine="#" in the langs.xml file with no luck.
View -> User defined Dialogue -> Comment & number -> Comment Line
There you type in "#"
Before this you need to define a new language in the upper buttons.
What means, that the whole rest of the syntax isn't highlighted anymore.
But you could define it that way, how you want to. So you have an individual Syntax Highlighting including the commenting via "#"
Probably quite a niche question, but I believe in the power of a big community: Is it possible to set up jEdit in way, that it automatically inserts a comment character (//, #, ... depending on the edit mode) at the beginning of a new line, if the line before the wrap was a comment?
Sample:
# This is a comment spanning multiple lines. If I continue to type here, it
# wraps around automatically, but I have to manually add a `#` to each line.
If I continue to type after the . the third line should start with the # automatically. I searched in the plugin repository but could not find anything related.
Background: jEdit has the concepct of soft and hard wrap. While soft wrap only breaks lines visually at a character limit, it does not insert line breaks in the file. Hard wrap on the other hand inserts \n into the file at the desired character count.
This is not exactly what you want: I use the macros Enter_with_Prefix.bsh to automatically insert the prefix (e.g., #, //) at the beginning of the new line.
Description copied from Enter_with_Prefix.bsh:
Enter_with_Prefix.bsh - a Beanshell macro for jEdit
that starts a new line continuing any recognized
sequence that started the previous. For example,
if the previous line beings with "1." the next will
be prefixed with "2.". It supports alpha lists (a., b., etc...),
bullet lists (+, =, *, etc..), comments, Javadocs,
Java import statements, e-mail replies (>, |, :),
and is easy to extend with new sequence types. Suggested
shortcut for this macro is S+ENTER (SHIFT+ENTER).
I'm using IDEA 13.0.1. A unit test is failing because of some line separator stuff. But when I try to compare the two results, IDEA says "Contents have differences only in line separators".
And I can't find a setting where I can say show me these differences. Is there one?
I ran into the same issue, I couldn't find a way to show the difference by clicking show differences, but if you put a break point and look at the strings, they have the line separator written out. For me one string had \n and one had \r\n. \r is also a possible line separator.
I ran into the same problem recently. I found a workaround for it, is not that pretty but did the job:
yourString.replaceAll("\n", "").replaceAll("\r", "");
The key is in what #user1633977 said.
To solve this problem, always use System.lineSeparator() to create your separators. That way they will always be the same and will be OS-independant.
(Remember that different OS can use different symbols as line separators).