1
$\begingroup$

Copy and paste the following two lines into Mathematica.

1 \[Alpha] \[NewLine] 2
f[ 1 \[Alpha] \[NewLine] 2]

The first posts \[NewLine] while the second doesn't. This doesn't duplicate the behavior as if you would have typed the same expression.

This should definitely be a bug IMO because it is both not displayed or interpreted. The same holds true for \[RawReturn] and \[IndentingNewLine]

Cell[BoxData[{
 RowBox[{"1", " ", "\[Alpha]"}], "\[NewLine]", "2", "\n", 
 RowBox[{"f", "[", 
  RowBox[{"1", " ", "\[Alpha]", " ", "2"}], "]"}]}], "Input"]

It doesn't copy the same behavior as if you would have typed the expression straight into Mathematica.

$\endgroup$
7
  • $\begingroup$ I don't think you can call it a bug unless you can point to where the docs say what to expect when you stick a non printing special character in the middle of an expression. $\endgroup$
    – george2079
    Commented Sep 3, 2015 at 15:00
  • $\begingroup$ @george2079 Does bribery work? I'll give rep points if I can mark it as a bug. :) Just Kidding. Although you are right it isn't documented but at the same time or don't think it should be the intended behavior. They are both multiplication \[Alpha] \[IndentingNewLine] working but not inside a function is inconsistent. $\endgroup$
    – William
    Commented Sep 3, 2015 at 15:02
  • $\begingroup$ @george2079 Each character has a name and a number of shortcut aliases. They are fully supported by the standard Wolfram System fonts. It doesn't matter to me if it displayed, but it should be interpreted. Check BoxData post above. $\endgroup$
    – William
    Commented Sep 3, 2015 at 15:13
  • 1
    $\begingroup$ @george2079 There should be an inconsistent-bug tag. I'm not sure about your original example it is debatable if Symbol@"\[IndentingNewLine]" should work. $\endgroup$
    – William
    Commented Sep 3, 2015 at 15:46
  • $\begingroup$ Ok, I see what you are saying. Its worth pointing out a regular "\[Newline]" works fine (displaying a line break within your function argument). ref: reference.wolfram.com/language/ref/character/… $\endgroup$
    – george2079
    Commented Sep 3, 2015 at 15:46

1 Answer 1

1
$\begingroup$

It isn't a bug but probably the intended behavior of automatic code formatter for "Input" Cells. Such Cells have AutoSpacing->True by default and so aren't intended to hold newlines, spaces etc. appearing in a string which you paste into them. If you wish to hold original appearance of the code you should use "Code" Cells (Alt+8) which has AutoSpacing->False or you could create custom stylesheet where "Input" Cells will have AutoSpacing->False by default.

When pasting your code into a "Code" Cell everything works as you expected:

screenshot

$\endgroup$
15
  • $\begingroup$ My issue is that if you take a valid box form of the data and type it in exactly it produces a different result then if you paste the same data into the cell. NewLine characters appear to be the only that have this happen. They are very much intended to hold new lines. It has been patched so paste works properly mathematica.stackexchange.com/questions/30604/… I'm ok with the \n but \[RawReturn] and \[IndentingNewLine] and \[NewLine] should not all be stripped. They are different characters. $\endgroup$
    – William
    Commented Feb 25, 2016 at 6:59
  • $\begingroup$ When you paste a string into an "Input" cell it is parsed having AutoSpacing->True "in mind". As I showed in my answer, it is sufficient to set AutoSpacing->False (even for "Input" cell) to prevent this. Try to add this option at the end of FullForm (Ctrl+E) of "Input" cell and then paste your code. You will see, it works! $\endgroup$ Commented Feb 25, 2016 at 7:04
  • $\begingroup$ I was not aware of this it definitely deserves a plus one. I'm surprised no body mentioned this before because it definitely works very similar to the other question. The one downside is it still doesn't distinguish between \[RawReturn] and \[IndentingNewLine] and \[NewLine]. After seeing this I kinda wish there was a hybrid AutoSpaces interpret NewLines but not spaces. That is essentially what the other question does. $\endgroup$
    – William
    Commented Feb 25, 2016 at 7:16
  • $\begingroup$ For what actually do you need \[NewLine], \[IndentingNewLine] and \[RawReturn] to be parsed differently when you paste a string? And in what way? With AutoSpacing->False they are all preserved and I see this as expected and correct behavior. $\endgroup$ Commented Feb 25, 2016 at 7:27
  • $\begingroup$ I'm fine with this not being marked as a bug although I still would still personally like to distinguish between them. Here is a very similar although slightly simpler example. If you export Mathematica code it wraps at lets say 80 characters...great. Well If you plan to reimport the code it is quit difficult to determine the original formatting because additional line breaks have been added for wrapping. Now if you wrap at 80 characters but include the \[LineBreak] and distinguish between the two you can essentially go back to the formatted code. Let me know if that doesn't make sense. $\endgroup$
    – William
    Commented Feb 25, 2016 at 7:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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