SlickEdit Community

Archived Beta Discussions => SlickEdit 201x Beta Discussions => SlickEdit 2013 v18 beta => Topic started by: jporkkahtc on June 11, 2013, 01:35:27 AM

Title: Auto-inserting NUL
Post by: jporkkahtc on June 11, 2013, 01:35:27 AM
I'm editing an android resource file
     <CR>
at the end of some of the lines.
The <CR> is a light grey color.

When I duplicate a line, the new line gets:
     <NUL>
at the end of the line.

Though, I'm pretty sure the file is in fact ANSI, 8-bit character.
(When I reload with the binary encoding option, I can see it really is 8-bit character).

Anyways, the file looks like this:

Code: [Select]
<?xml version="1.0" encoding="utf-8"?>
<resources><CR>
<CR>
    <string name="local_string_1">SnapCam</string><CR>
</resources>


Anyways, I put the cursor on the <String> line, copy - n - paste to duplicate that line.
A new line is inserted above the old, not intented and now with a <NUL>


Code: [Select]
<?xml version="1.0" encoding="utf-8"?>
<resources><CR>
<CR>
<string name="local_string_1">SnapCam</string><NUL>
    <string name="local_string_1">SnapCam</string><CR>
</resources>
Title: Re: Auto-inserting NUL
Post by: jporkkahtc on June 11, 2013, 01:39:42 AM
The problem appears to be because the <CR> lines have a line ending of
    0d 0d 0a
This double-CR thing appears a bunch in Android code on Windows.
"adb logcat" for instance dumps all text this way.
I don't know why my strings.xml file ended up this way, presumably because ADT made it so.
Title: Re: Auto-inserting NUL
Post by: patrick on June 11, 2013, 01:45:34 PM
Reproduced it, we'll take a look at it.
Title: Re: Auto-inserting NUL
Post by: Matthew on June 11, 2013, 01:50:28 PM
We had another user report the same problem a couple weeks back where Android resource files were getting this mixed line ending issue.

You can fix this is SE a couple ways, but I find the quickest is to do a command-line replacement to get you to a sane line ending.
Code: [Select]
c/\13\13\10/\13\10/r*
Title: Re: Auto-inserting NUL
Post by: patrick on June 12, 2013, 05:40:48 PM
The underlying problem that caused the <CR> to be replaced with <NUL> has been fixed for the next drop.