- Hi Axel,
One way to deal with this is to use a regular expression replace,
to replace every occurrence of a linefeed NOT preceded by a Carriage return with your choice of replacement string, i.e.:
"([^\r])\n" with "$1X",
where X is the character/string you want to replace the solitary linefeeds with.
You could do this in a clip or the interactive search.
This does NOT answer the question if NoteTab treats lf differently, or not. I have never knwoingly encountered MIXED end-of-lines in a file.
--- In email@example.com, Axel Berger <Axel-Berger@...> wrote:
> Were there any changes in the treatment of linefeeds to version 5.8?
> I have some files containing linefeeds ($0a) as well as correct
> newlines ($0d0a) and I need to replace the linefeeds with something
> else. Loading such files in version 5.8 treats all these as full
> newlines and I can't get at the $0a or ^L any more. I remember this
> used to work once.
> What can I do?
- ebbtidalflats wrote:
> One way to deal with this is to use a regular expressionDoesn't help. The file definitely contains 0a as well as the normal
0d0a, but after opening it in NoteTab all these are changed to 0d0a.
A search for [^\r]\n finds nothing. This means just opening that
file in NoteTab changes it and the very things I need to look for
are no longer there. I may have to devise a complicated workaround.
- --- In firstname.lastname@example.org, Axel Berger <Axel-Berger@...> wrote:
>I made a test file and loaded it in both 5.7 and 5.8 and both seemed to handle my test file the same. But that's not to say that my test conditions match your file. My test file had:
> ebbtidalflats wrote:
> > One way to deal with this is to use a regular expression
> Doesn't help. The file definitely contains 0a as well as the normal
> 0d0a, but after opening it in NoteTab all these are changed to 0d0a.
> A search for [^\r]\n finds nothing. This means just opening that
> file in NoteTab changes it and the very things I need to look for
> are no longer there. I may have to devise a complicated workaround.
^L finds the single LF and no other. All the others are found by ^P (except the single LF). It appears the single CR has been converted to CRLF, it is not found by ^C. But the behavior is the same in 5.7. The file also looks the same when loaded in both versions with no linebreak at the single LF. Finally I tried saving the file in NoteTab to a new file in both versions, and this was also the same. In both cases, the single Carriage Return (0D) became 0D0A and the single Line Feed (0A) remained unchanged.
Maybe what you think were single line feeds were actually single carriage returns?
- Sheri wrote:
> Maybe what you think were single line feeds were actuallyNo, when things began not to work as expected I checked everything
> single carriage returns?
in the Hex view of Totalcommander. The raw files I'm dealing with
are in the Atari or nearly the CP437 character set. As they usually
need converting anyway one more conversion won't hurt, so I'm now
writing caracter 219 ($DB) instead of the 0A.
I then hit two more problems:
1) Loading the file as DOS ASCII converts the $DB to space, no good.
2) Loaded as Ansi I can easily replace the $DB, shown as Û (capital
U with circumflex). But in a clip neither the cut and pasted Û nor
^$DectoChar(219)$ worked. (^$DectoChar(219)$ as a clip on its own
writes the correct character into a file though.) I was just
starting to cry for help here again when I tried the third option,
and voilà, using Regex and \xDB did the trick.