Just tested TEDIT 0.69 with "mixed" LF+CR,LF text file. So, it reads the line break from the first line and sets it as standard for the opened file, then on save it writes line breaks according to this. Seems Ok to me.

aVd wrote on 2026-04-05, 13:31:

... it reads the line break from the first line and sets it as standard for the opened file, then on save it writes line breaks according to this ...

Given "8086 16-bit", screenshots and lots mention of "DOS" in this thread, I've been assuming that this IS a DOS editor.

In which case I don't see a reason to set the type of line-break writtene to files.
IMHO a DOS text editor should write standard DOS text files (ie: CR,LF line-breaks)

I get that a single LF is prefferable, but DOS was written in the days where everything was oriented to what could be sent directly to a terminal or printer without all that excessive "processing" needed to make it truly printable.

I do find it annoying when I have to work with a text file from *nix with some DOS software that insists on the CR,LF and doesn't understand text files from better OSs, so you have to "convert" it.

What I do personally is my DOS editor uses newline (LF) and ignores CR when reading - so it has no trouble understanding files of either line-break type (it can even deal with files that are LF,CR - which were used in some classic OSs)

When writing the file, it used DOS standard line-breaks. So... when I get a *nix file with only LFs, I just have to load it into my editor and resave it to make it fully compatible with all DOS software.

Hi, @DaveDDS,
Latest version of TEDIT "understands" perfectly fine those two standards for line break. It visualizes them correctly even in "mixed" text files. Yes, it's a DOS text editor, but modern one, and it's nice to have this conversion feature.

Let's assume, that we have a rare case of DOSBox in Linux and have to edit a *nix text file - why changing its standard by default? If we need to do so - there's a conversion option in the menu (and possibly a keyboard shortcut in the future - some Fn key for example).

P.S. Maybe "LF" is more preferable (and saves some bytes), but when using DOS/windows it's not, and I don't like to see a source code for DOS/windows programs written in *nix environment with no respect for different line break standard 😀

Good point - I hadn't though about DosBox on *nix ...

If would be ideal if DosBox itself could handle the conversion, but I don't think this is really possible since text/binary file access mode isn't handled by DOS itself in so many cases.

A lot depends on the development tools used to write DOS programs. I've run into a *lot* of DOS software which works with text files and just can't handle them without CR,LF line-breaks.

If you move things back and forth between DOS/Win and *nix, you really need to get proficient at converting. This is why my DOS "CP" (copy) command has a -U option to convert line-breaks to<>from Unix line-breaks.

But... being a "purist", I still think that DOS software should write DOS standard text files (with perhaps an option to write *nix).

It really becomes a question of why you are accessing host files within DosBox if not to use them ongoing in DOS... Why would you fire up DosBox just to edit a host file? I would think "to use it with DOS stuff" would be a more common answer than "I just like editing in DOS more"

I fully agree with your "purist" attitude, @DaveDDS. And that's why I think, that TEDIT shouldn't mess with the text file line breaks, if not explicitly forced to do so. I often use DOSBox in Linux for quick tests of different DOS programs or even different DOS versions (it can be "rebooted" with option to load OS from mounted floppy or HDD image). For example, when DOSBox is used in full screen mode, sometimes it's faster to use m$ EDIT or other DOS text editor to change something in CONFIG.SYS and AUTOEXEC.BAT, than "switching back" to host OS, starting file manager, browsing for the file... etc.

Maybe an indicator with red background for "LF" (*nix standard) will be more cautious, than the current one. Just to remind to user, that currently edited file is not of a DOS/windows standard.

I guess we have a different idea of what "purist" means. To me it means DOS stuff should write DOS compatible text files. To you it means DOS stuff shouldn't change the format of text files - both are valid viewpoints and there are cases where you want either behavious. (really the only thing that sightly favors mine is that the code would suffer some bloat in dealing with files it should never see in DOS, and yours is that text files not for to DOS wouldn't get slightly bigger)

I can think of one case where I write a file to be used omn the host from within DosBox - I have tools to update the DosBox configuratuib file from within DosBox (this is why my edition of DosBox uses "DOSBOX.INI" instead of "DOSBOX.CONF" -avoid long filename which some DOS tools can't handle.

I've not run into problems because I rarely use Linux - I boot it in VMWARE sometimes (and actually have one physical Linux system) which I do only when I want to test something.

I've not tried, hopefully DosBox itself can read a configuration file with either type of line-breaks.

I do like the idea of showing a more prominent indicator that the file you are editing is non-DOS-standard format.