On 11/12/2012 04:33, Troy Gillette wrote:
We have several million lines of code from the last ten years. C, C++,
Objective-C, Ruby, Python, XML, numerous others... Nothing in our
process cares whether anything ends in LF or CR+LF, but BBEdit does.
I think, in contrast to some others, that you have a good point. And the
point is that BBEdit, having determined, by a test of the first line or
so, that the line-endings are one byte then proceeds to convert each
individual \r or \n into the default line-ending. In my case that is \n
and a mixed document such as you are talking of, will end up with \n\n
where there was \r\n and there is no way to distinguish in BBEdit
between what was a DOS line end and what was a blank line.
So the only way to resolve the problem is to regularize the line endings
before BBEdit gets its hands on the doc. The best way to do this, it
strikes me, is to run all the files through a UNIX or Perl filter in one
go, converting every line-end byte or pair to \n and get rid of the
problem at source once and for all. This is very easy to do.
On the other hand I do think it is something that BBEdit should do
automatically, because it makes no sense to convert \r\n to \n\n, as now
can happen, under any circumstances.
JD
--
--
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 bbedit@googlegroups.com
To unsubscribe from this group, send email to
bbedit+unsubscr...@googlegroups.com
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 "supp...@barebones.com" rather than posting to the group.
Follow @bbedit on Twitter: <http://www.twitter.com/bbedit>
