4

I find that copying a code block from Stack Exchange, as viewed from Internet Explorer 11 (but not FireFox) to Mathematica loses line breaks. This is inconvenient at best and produces errors at worst. A work-around is to copy the code block to Notebook and from there to Mathematica. Is there a better approach, apart from abandoning IE11 in favor of FireFox? Thanks.

  • 1
    Do you see the same behaviour when you paste it not in an Input cell, but rather a Code cell? – halirutan Mar 13 '15 at 15:36
5

You could paste the code into a Code cell rather than an Input cell. That will preserve indentation, but has the disadvantage automatically setting the Initialization Cell property. You can remove that property, but to constantly do that can be a nuisance.

You could also derive a new cell style from the Code style that does not set the Initialization Cell property.

  • This certainly works, and is more convenient than using Notepad as an intermediary. Thanks! What, exactly, is a Code cell? I see that it is an Initialization cell by default and that it is a different color (grey on my computer). Does it have other properties that distinguish it from an Input cell? – bbgodfrey Mar 13 '15 at 16:36
  • No other properties that I know of, but Code cells are the style normally used in packages for code that is to be evaluated at load time. Needs and Get only evaluate initialization cells. – m_goldberg Mar 13 '15 at 16:42
5

Here is an automated approach. I was able to figure out a way to avoid using Paste[]. The key ingredient here is to use

MathLink`CallFrontEnd@UndocumentedTestFEParserPacket[string, False]

which rm-rf told me about.

I think I am going to find this very useful and I will probably bind this to a hotkey. It almost feels like this question has to be a duplicate. Here is the definition

printInputCellUsingClipboard::usage = 
  "Prints a cell like paste will do, but preserves indentation for \
strings. Takes the same options as Cell.";
printInputCellUsingClipboard::dataTypeError = 
  "Wrong kind of data on clipboard";
printInputCellUsingClipboard::invalidOption = "Invalid option given";
pICUCDefaults = {GeneratedCell -> False, CellAutoOverwrite -> False, 
   CellTags -> {}};
printInputCellUsingClipboard[cellOpts : OptionsPattern[]] :=
 Block[{data, succes, cell, optsWithDefaults},
  succes =
   Quiet[
    Check[
     Options[Cell, {cellOpts}[[All, 1]]]; True,
     False, 
     Options::optnf],
    Options::optnf];
  If[
   succes
   ,
   optsWithDefaults = 
    Normal@Association@Join[pICUCDefaults, {cellOpts}];
   data = NotebookGet[ClipboardNotebook[]][[1, 1, 1]];
   succes =
    Switch[
     Head@data,
     String,
     data = 
      First@MathLink`CallFrontEnd@
        UndocumentedTestFEParserPacket[data, False];
     True,
     BoxData,
     True,
     _,
     False
     ];
   If[
    succes
    ,
    AbortProtect@PreemptProtect[
      CellPrint@Cell[data, "Input", CellTags -> "tempClipboardCell"];
      cell = First@Cells[CellTags -> "tempClipboardCell"];
      SetOptions[cell, optsWithDefaults]
      ]
    ,
    Message[printInputCellUsingClipboard::dataTypeError]
    ]
   ,
   Message[printInputCellUsingClipboard::invalidOption]
   ];
  ]

About options and such

I spent quite some time thinking about to handle messages, failures and options. A large part of the code above deals with those issues.

I decided not to rely on OptionValue magic. Using OptionValue would have made our function definition huge, if we wanted to be able to be able to change default options without redefining the function. The reason for this is that OptionValue has to be in "the right places" at the time the function is defined. This would mean we would have a opt -> OptionValue[opt] for every option of Cell.

Unfortunately, the approach I choose means we cannot use functions like Options and SetOptions to get and set the options of printInputCellUsingClipboard. On the plus side, we can use any ("unnested") option of Cell, without having to deal with an extremely long list of default option values, like the expression Options[Cell] yields.

A reasonable alternative would have been to set options using Options[printInputCellUsingClipboard] = {...}, but to set only a few options this way, even though we would allow for more options. I felt this approach was misleading, as only some options would have been mentioned in Options[printInputCellUsingClipboard].

I used a trick with Association to get rid of duplicate options.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .