Welp. CHR 13 becomes CHR 10 in files.

Choose a symbol that few people use. Most things that use CHR$ and ASC only work with ASCII anyway, so it won't cause problems.

Choose a symbol that few people use. Most things that use CHR$ and ASC only work with ASCII anyway, so it won't cause problems.

"640 k ought to be enough for anybody."

This is the solution I am using:

DEF TO_SAVESTRING A$ OUT RESULT$
 RESULT$=""
 VAR I%,B$
 FOR I%=0 TO LEN(A$)-1
  B$=A$[I%]
  IF (B$=="\") THEN
   B$=B$*2
  ELSEIF (B$==CHR$(13)) THEN
   B$="\D"
  ENDIF
  PUSH RESULT$,B$
 NEXT I%
END

DEF FROM_SAVESTRING A$ OUT RESULT$
 RESULT$=""
 VAR I%,B$
 WHILE (I%<LEN(A$))
  B$=A$[I%]
  IF (B$=="\") THEN
   INC I%
   IF (I%<LEN(A$)) THEN
    B$=A$[I%]
    IF (B$=="D") THEN
     B$=CHR$(13)
    ENDIF
   ENDIF
  ENDIF
  PUSH RESULT$,B$
  INC I%
 WEND
END

SAVE "TXT:TXTFILE",TO_SAVESTRING(A$)
A$=FROM_SAVESTRING(LOAD("TXT:TXTFILE"))

Hm. Backslash "\" appears as \. Doesn't really matter as long as it's the same character in both places.

The backslash codepoint as we know it is mapped to the yen symbol in the font. Supposedly this has something to Shift-JIS versus ANSI. Of course, you could just change the font graphic, but that's not really the same. You could also use that funny-looking backstroke, but that isn't the same either.

Choose a symbol that few people use. Most things that use CHR$ and ASC only work with ASCII anyway, so it won't cause problems.

Not sure what you mean. CHR$ and ASC map to SB's character encoding scheme. And like I said, you could just change the font graphics.

*sigh* I guess I'll just use DAT? Actually thinking more, I might need DAT in my case.

The only thing that this "feature" affects is code encryptors. You shouldn't use TXT files to store numerical data anyway. And with encryptors, you can assume that no one will use a certain obscure character in their code, like one of the thousands of [x] characters. So, make your custom ASC and CHR$ functions use that character, and the problem is as close to solved as it will ever be.

The only thing that this "feature" affects is code encryptors.

No, this bug affects anyone who wishes to store text strings, which may include the character CHR$(13), in a file.

And with encryptors, you can assume that no one will use a certain obscure character in their code, like one of the thousands of [x] characters.

First of all, you can't assume that the user will not use any particular character, and second of all, you cannot assume that the encrypted output will not have any particular character, which is the issue you face if you want to save an encrypted file.

...and the problem is as close to solved as it will ever be.

The problem can be more than 'close to solved', it can be actually solved, by 'escaping' CHR$(13) (and the 'escape' character you choose) just before saving, and undoing the process just after loading.

having an escape character is annoying then you have to escape THAT character... But I guess it does solve the problem. You never need to store CHR$(13) in a file. If you want to store numerical data, use DAT. If you want to store text data, then it doesn't matter because CHR$(13) can just be replaced by something else.

having an escape character is annoying

Yes. But the choice here is between (a) annoying because it's broken, and (b) annoying but not broken.

You never need to store CHR$(13) in a file.

Indeed. You never "need" to store anything other than CHR$(0) in a file - you can use the length of the file to encode any information you might wish to store.

If you want to store numerical data, use DAT. If you want to store text data, then it doesn't matter because CHR$(13) can just be replaced by something else.

For a certain definition of "text data" that you're thinking of. For a definition of "text data" something like: "a sequence of characters" (surely a reasonable definition), it does matter.

Just because you don't NEED to doesn't mean you wouldn't want to. In my case, I had to use a TXT file to encode text data in some structure. Each entry in the save table was led by a length word: for example, if the length of the entry was 25, CHR 25 would be put there. If the length was to be 13, guess what: the file is broken. This is more of a problem than you may realize. I could encode the length word as text, but that would bloat the file size.

Just because you don't NEED to doesn't mean you wouldn't want to. In my case, I had to use a TXT file to encode text data in some structure. Each entry in the save table was led by a length word: for example, if the length of the entry was 25, CHR 25 would be put there. If the length was to be 13, guess what: the file is broken. This is more of a problem than you may realize. I could encode the length word as text, but that would bloat the file size.

That's exactly the kind of thing what I was working on.

use DAT then. TXT files are designed for storing program files, or simple text data like names There is no reason to abuse text files

There is no reason to abuse text files

There is no reason inclusion of CHR$(13) should be an abuse.

Saving non-text data in text files was never intended. Give me one example of something that could be saved in a text file but not an array.

Saving non-text data in text files was never intended.

This is not an issue about the inability to save non-'text' data in a text file, for the reasonable definition of 'text' as 'a sequence of characters from the character set'. This is about the inability to save text data to a text file.

When do you need to save CHR$(13) in a text file?

When do you need to save CHR$(13) in a text file?

No answer I give changes the bug from being a bug. Why even ask?

Because I want to know why you think this is so annoying. It's not a big deal (and not a bug).

Because I want to know why you think this is so annoying. It's not a big deal (and not a bug).

It is annoying because it is a bug. You have made it clear that in your opinion of what constitutes 'text data', there is no harm in a lack of CHR$(13). Among experienced programmers, this is a minority opinion. EDIT: This, actually, might be a promising direction to pursue so we can amicably agree to disagree. I have given a working definition of what I would consider, generally, "text data", and that is, "a sequence of characters from the character set". So far, the closest you have come to defining what you would consider, generally, "text data", is "program files, or simple text data like names". "a sequence of characters from the character set" vs. "program files, or simple text data like names": which do you think works better as a definition? Do you want to put forward another definition of what you consider "text data" to compare against mine?

Do you want me to store my text sequence in a DAT file? That would cause an even more significant amount of effort and grief on my part. Things should be expected to work properly. To use the save format I planned in the way I intend, are you suggesting I split the data amongst two files? I don't think so. Look, my definition of bug may be different from anyone else's (I think this is just a very bad design choice, but whatever) but at any rate, it's a problem. At the very least, they could document this.