At 17:51 -0800 12/10/12, Troy Gillette wrote: >I work on a large cross-platform project for Mac and Windows. Every editor >used on the Windows team treats UNIX and Windows style line endings as if it >is simply a native carriage return. So if any mixed line endings end up in a >file, it is completely transparent. > >Xcode, TextMate and even TextEdit on the Mac do the same thing. > >BBEdit on the other hand, looks at the first line of the file and assumes ALL >other line endings in the file match that one. So, if you open a file with a >UNIX line ending on the first line, any lines with Windows EOLs will end up >with a second empty line after them and if the first line is Windows style, >any UNIX lines will get mushed together into a single line. > >The only way I see to fix this is to make the entire file conform to one or >the other. This can be a real pain, especially if only the first few lines are >different because it will mess up everything after that (I see no way to force >bbedit to load one way or the other, it always chooses for me). It also >results in excessive/unnecessary changes in revision control. > >I understand there are times when you would want to be able to know there are >differing line endings, but the current system makes life difficult for those >of us who must cooperate with developers outside of the Mac world. > >Is there a chance that we could have a preferences option to make BBEdit >behave like every other developers editor on the market? >Is there already such an option that I just can't seem to find?
I feel your pain. BBEdit's editing procedure demands that line ends all be the same while displayed in an editing window. They are converted as desired to the output format on a save or when a copy is put onto the system clipboard. Linux' gedit has pretty much the same problems. Nisus for OS 9 is nice but unsupported and the neXt version is too different. Simpletext is a solution of sorts but only on classic machines. VI... . . Naah. Have a close look at the format of a BBEdit worksheet. It's actually an Apple *.plist file and the guts of the content is a single binary entry that's buried in a cell of the underlying XML. The XML uses 0A line ends and the "binary" data is the worksheet. with its 0D endings. You cannot edit a bbedit worksheet using the bbedit editor. I work with strange electronic devices like oscilloscopes and digitally controlled power supplies and other machinery. Some of it actually requires different kinds of line ends but the ends are simply never the same so there is no way to prepare a report in BBEdit that needs to contain samples of code or measured data. <ftp://macnauchtan.com/Software/LineEnds/> contains some AppleScripts that I think will still work to "repair" files with divers ends. I'm stuck, though, at 10.3.9 because Tiger refused to honor my SE/30 file server and newer Macs won't talk RS232 to my machinery. God help the world when the two new UTF-16 line ends, soft and hard, that now exist, become popular. And long live Apple's MPW which can edit its own worksheets and then execute them by name. And I also want tab stops that work like my Olympia typewriter or an 026 keypunch. -- Fe++ // \ Fe++ Fe++ | || Fe++ Fe++ \\ / Fe++ -- -- You received this message because you are subscribed to the "BBEdit Talk" discussion group on Google Groups. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at <http://groups.google.com/group/bbedit?hl=en> If you have a feature request or would like to report a problem, please email "[email protected]" rather than posting to the group. Follow @bbedit on Twitter: <http://www.twitter.com/bbedit>
