line breaks in generated files

[Robert Cailliau]

I am writing text files from a program, using ASCII LF for line breaks.

When opening such a file with BBEdit, it shows, at the bottom of the window in the status bar, the line break type as "Classic Mac", i.e. ASCII CR.

So my question is: what information in the text file is used by BBEdit to decide what to show as the line break type?

[Greg Shenaut]

First, I'd look at the file with (e.g.) od -c to make sure what's there.

Greg Shenaut

--
This is the BBEdit Talk public discussion group. If you have a
feature request or would like to report a problem, please email
"sup...@barebones.com" rather than posting to the group.
Follow @bbedit on Twitter: <http://www.twitter.com/bbedit>
 
---
You received this message because you are subscribed to the Google Groups "BBEdit Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bbedit+un...@googlegroups.com.
To post to this group, send email to bbe...@googlegroups.com.

[Robert Cailliau]

There are LFs: decimal 10.

But I just found my answer and thereby two "bug/features" to report:

The Open dialog has a check-box "Translate line breaks" which was checked.

The manual (10.5.4) states "When this option is selected, BBEdit translates Windows or Unix line breaks..." (but does not specify into what; it must be Mac CRs)

and also states "Unlike the other options in the Open dialog, the setting of this option is not preserved between uses of the Open command,..." which is true since it always falls back to translating.  Which I do not want.  I'll request a feature to be added (an extra checkbox "preserve this setting")

The last set of BBEdit's preferences is about "Text Files" and there one can choose one of three radio buttons Unix/Classic/Windows, but it is unclear what effect that choice has.

While editing one does not really care, but when reading and writing the file it may be important that line breaks are not changed.

BBEdit cannot store some indication with the file to remember which type of line breaks to use.  I suspect that it stores (or could store) this information in the same .plist file where are also kept the window positions and other info about files that have been opened once.

Since these particular files are opened after they have been generated, and BBEdit has no info about them in its .plist, I suspect it translates the line breaks and selects "Classic Mac".  But it needs some more experimenting.

OK, thanks, and subject closed for the time being.

[Rich Siegel]

On Saturday, December 14, 2013, Robert Cailliau

<caillia...@gmail.com> wrote:

>There are LFs: decimal 10.
>
>But I just found my answer and thereby two "bug/features" to report:
>The Open dialog has a check-box "Translate line breaks" which was checked.
>The manual (10.5.4) states "When this option is selected,
>BBEdit translates Windows or Unix line breaks..." (but does not
>specify into what; it must be Mac CRs)
>and also states "Unlike the other options in the Open dialog,
>the setting of this option is not preserved between uses of the
>Open command,..." which is true since it always falls back to
>translating. Which I do not want.

What problem are you trying to solve?

>The last set of BBEdit's preferences is about "Text Files" and
>there one can choose one of three radio buttons
>Unix/Classic/Windows, but it is unclear what effect that choice has.

That setting establishes the default line-break type for new documents.

>BBEdit cannot store some indication with the file to remember
>which type of line breaks to use.

That information is derived from the file's contents; namely,
which characters it uses for a line break. For performance and
practicality reasons, BBEdit examines the first line break in
the file and uses this as the basis of its determination. If
you're writing files programmatically, and the first line break
you write out is a carriage return ("\r", ASCII 13, \015, etc)
then the file will be interpreted as such. You probably want to
use a line feed ("\n", ASCII 10, \012), and do so consistently.
Attempting to store line break format external to the file would
be unreliable and fragile.

R.
--
Rich Siegel Bare Bones Software, Inc.
<sie...@barebones.com> <http://www.barebones.com/>

Someday I'll look back on all this and laugh... until they
sedate me.