Take the 2-minute tour ×
Mathematica Stack Exchange is a question and answer site for users of Mathematica. It's 100% free, no registration required.

When I run the following code in an empty notebook

SetOptions[EvaluationNotebook[], testOption -> "\n\r"]

and then open the notebook in Notepad, I find

$CellContext`testOption -> "\n\n"

(1) Can you confirm this bug/feature in other versions/operative systems? I am using Mathematica 9.0.1 in Win8Prox64.

(2) Is there a workaround?

share|improve this question
2  
I have tested it in Win7x64, Mathematica 9.0.1 and this is set, as desired, to \n\r –  Ailton Andrade de Oliveira Oct 3 '13 at 16:17
2  
\n is newline and \r is carriage return. It's OS specific because running your line and saving and reading into TextEdit on Mac OS gives $CellContexttestOption -> "\n\n"` –  bill s Oct 3 '13 at 16:42

1 Answer 1

up vote 1 down vote accepted

I see the same behavior in Win7Prox64/Mathematica 9.0.1.

I may be missing something but AFAIK adding arbitrary new options to a notebook object isn't a documented/supported feature. So you'd have to accept whatever this does and also if it wouldn't work at all. The only useful purpose of such an unkown option that I can think of is to store extra information in the notebook object and the corresponding notebook expression. For that there is the documented and supported TaggingRules option which lets you store extra rules to notebook objects. Using TaggingRules receiving the information is also supported and working using the two argument version of Options and CurrentValue (which both won't work with an unknown option). So you might want consider using TaggingRules instead of introducing a new option.

As for the conversion of the string: If you get back the string in the same session with testOption /. Options[EvaluationNotebook[]], the \r will remain, only when it is written to file it is converted to \n. When reopening the notebook from file, one will also get the converted \n with Options[EvaluationNotebook[]]. Maybe that can explain why not everybody reports the same behavior even on similar systems, but it could also be some setting or a sideeffect of a setting. It might be worth noting that the exact same thing does also happen when you use TaggingRules.

One thing that comes to mind as a workaround is to Compress before setting and Uncompress before reading (shown here with CurrentValue and TaggingRules):

CurrentValue[EvaluationNotebook[], {TaggingRules, "TestOption"}] = Compress["\n\r"]

CurrentValue[EvaluationNotebook[], {TaggingRules, "TestOption"}] // Uncompress // InputForm

the resulting string shouldn't contain any special characters that would be touched when writing to file. Of course the resulting file content isn't human readable, so whether that is a useful workaround for your problem depends on what you try to achieve. You might want to explain that in more detail for better suggestions...

share|improve this answer
    
The (made up) option was for the purposes of a minimal working example. The main problem is that the string is part of a button that is docked. The Uncompress trick will do. –  Hector Oct 4 '13 at 13:45

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.