On Sat, Jul 18, 2020 at 18:53:34 +0200, Benno Schulenberg wrote: > > Op 13-07-2020 om 01:56 schreef Nils König: > > Basically, I imagined this just like: > > > >> If nano were to handle a BOM properly, it must remove a BOM whenever > >> a file is read, and add it back when it is written. But that would > >> make it impossible to delete an unwanted BOM with a simple backspace. > >> Then the user would need to fall back to a tool like dos2unix. > > > > But without the need for an external tool to remove a BOM, instead this > > could > > be toggled in the save dialog. > > You want to have it both ways. 1) You want nano to hide the BOM from the > user -- because the BOM is part of the file format and must of course stay > where it is. And 2) you want to be able to remove the BOM in some way. > > But... in what circumstances would you want to remove the BOM?
If everything goes well a BOM is only present if really required for compatibility. If things don't go so well, I could imagine that an unneeded or unwanted BOM might slip in if a file was edited on another platform. And might subsequently lead to parsing issues with eg software expecting ASCII-only or BOM-less UTF-8 input and checks for some magic character sequence at the start (like '#!') > Another question. These *.ass files, are they in DOS format? > Or do you also have Unix files that start with a BOM? Funnily enough, while aegisub will always add a BOM to UTF-8 *.ass files, it will use the system default for linebreaks, in my case UNIX CR. *.ass files automatically created by ffmpeg on the other hand will always use DOS CRLF linebreaks. Nils
