TextInputStream.Delimiter ?

General
1

I just fall on TextOutputStream.Delimiter (sort of discovering it) and I found that nice.
(No, I never noticed or I forgot TextOutputStream.Delimiter).
After a simple search, it seems that TextOutputStream.Delimiter exists in REALbasic for many years, if not from the beginnings (REALbasic 1.0)

TextOutputStream.Delimiter The character used to mark the end of a line of text written to the file. The OS default for EndOfLine is used.

TextInputStream does not have this Property.

Yes, as someone I thank again says: "you can read the whole file with ReplaceLineEndings, save it and load it normally as you actually do”. But this is a work-around who have to be done by 200,000 Xojo users while adding a Delimiter property to TextInputStream have to be done once.

Why ?
Is this too hard or impossible to do ?

What is your feeling on that ?

PS: I falled once more on that yesterday, but I was lucky to remember from where the text data comes before I put it into a TextEdit window: Safari text from an old eml file. So, I’ve made in Apple’s TextEdit a <fœŒŸÎË-cr> replace all by chr(13)… and all goes well (until sometimes in the future when I will forget what happens !)

PPS: AppleScript have this kind of thing (and much more) to load data from text files. The command ask something like: rad from file XyZ until . Isn’t this powerful ?

2

Typically with text streams you would writeline & readline. The only issue is when lineendings are different - i.e. different os then you need to use replacelineendings. I can for instance on any version of windows use writeline & readline without problems however using writeline on OSX & readline on Windows may not be compatible.

The whole thing goes back to the very old days of teletype machines where and end of line was a carriage return followed by a line feed. These were two different commands to allow underlining which involved two passes of the print head one to print the letters & the second to underline the appropriate places. Since then some OS’s have dropped the Line Feed &H0A and left just the carriage return &H0D. Windows still uses &h0D + &h0A.

And that’s why there’s ReplaceLineEndings.

Of course back in the day when I was working on these things life was easy - ASCII, EBCDIC all 7bits - none of this modern UTF multibyte stuff.

3

Thanks @Wayne Golding , just what I was looking for rather than building a function myself.