I have reported this issue: [CASE:3389542]

Today, I accidentally found what I believe is an unwanted feature of the front-end, where input code is not appropriately highlighted and the dynamic highlighting of e.g. matching braces doesn't work.

Very simple example:

ArrayPlot[RandomReal[1, {2, 2}]] // InputForm

This gives as expected an ouput-cell that contains code

Mathematica graphics

Now, I have three choices when I want to edit this code

  • just go inside the output cell and start typing
  • use Ctrl+Shift+L to Copy output from above into a new input cell
  • copy the cell with Ctrl+C and paste it

When I use the first method, I noticed that highlighting and brace matching doesn't work. The same is true for the second method iff you go under the output cell without creating a new input cell (by pressing a key and deleting the char for instance).

The code looks then like this, where you should note the missing highlighting of the option strings:

Mathematica graphics

Can someone confirm this behavior? I have seen it on Linux and Mac OS X both running 10.2.

Note, I have not described the issue extensively. For instance the underlying cell-expressions look different for copy&paste code compared to Copy output from above code. I hope the issue is described in enough detail to reproduce it at WRI.

  • $\begingroup$ I see it on 10.1 and 9.0.1, Mac OS X. $\endgroup$
    – Michael E2
    Commented Jul 21, 2015 at 23:33

4 Answers 4


It has been like this for a long time, hasn't it? At least since version 7. I always assumed that InputForm (the Head, not the format) wasn't really intended for reentry, though since it does mostly work I guess it should work completely. Most of the time I just let the output render, select it, and use the menu command: Cell > Convert To > InputForm (Shift+Ctrl+i).

As has been noted by Alexey Popkov before using another head around InputForm produces a different formatting, one that you would seem to prefer, so you might use:

ArrayPlot[RandomReal[1, {2, 2}]] // InputForm // DisplayForm

You may also consider PlainForm or CodeForm from the GeneralUtilities package:


ArrayPlot[RandomReal[1, {2, 2}]] // PlainForm
  • $\begingroup$ When used with Ctrl+Shift+L for insert output from above, the only thing that works is //InputForm//DisplayForm. Plainform doesn't and returns the same non-highlighting input like here, except when I go directly in the output and convert it to "InputForm" with Ctrl+Shift+I. $\endgroup$
    – halirutan
    Commented Jul 26, 2015 at 14:07
  • $\begingroup$ @halirutan PlainForm appears to work correctly with Ctrl+Shift+L in 10.1 under Windows, e.g. Hold[Solve[y = x, y]] // PlainForm then Ctrl+Shift+L shows expected syntax highlighting. Can you give me a counterexample? $\endgroup$
    – Mr.Wizard
    Commented Jul 28, 2015 at 15:41
  • $\begingroup$ It seems I mixed something up because the coloring is OK. But did you noticed that strings are turned into fake symbols?? Look here where "QuasiNewton" seems to by symbolized. It is still a string and you see this the first time you hit a key in this new cell :-) $\endgroup$
    – halirutan
    Commented Jul 30, 2015 at 0:20

The problem is that a cell made with Cmnd+Shift+L has form

Cell[BoxData["...", "Output", "Input", FormatType -> "InputForm"]

The code editor only likes cells with the form

Cell[BoxData["..." , "Input"]

If you were to open the cell with Cell > Show Expression (Cmnd+Shift+E) edit to remove "Output", and FormatType -> "InputForm", all would be well. Of course, you shouldn't have to do that.

Clearly, the Cmnd+Shift+L should behave more intelligently.

  • $\begingroup$ On Linux with version 10.2 I see something completely different. No BoxData and not FormatType for me. Anyway, it's something that should work and that we cannot fix ourselves. It's not even a big issue, but I'm kind of pedantic when it comes to UI and usability. $\endgroup$
    – halirutan
    Commented Jul 22, 2015 at 0:44
  • $\begingroup$ @halirutan. I am running 10.1 on OS X. I'm surprised that you see such a different cell form. But I'm entirely with you on UI usability. $\endgroup$
    – m_goldberg
    Commented Jul 22, 2015 at 1:18
  • $\begingroup$ On Windows 7 x64 with version 10.2 I see the same as @halirutan: no BoxData and FormatType. $\endgroup$ Commented Jul 28, 2015 at 8:59

Here is the conversation I had with the support. First response from [email protected]

Using InputForm returns an expression suitable for input, so when you change it it becomes an input expression. Please useToString to generate a string in input form:

ToString[ArrayPlot[RandomReal[1, {2, 2}]], InputForm]

Mathematica graphics

That indeed did not help me because my question was a different one. Therefore, I tried to explain it further

Hi [name],

I don't want to create a string in InputForm. There seems to be a bug in the front end that makes that code is not properly highlighted when you use Ctrl+Shift+L to insert ouput code from above that was displayed as InputForm. Please evaluate the following code (that is held with Hold and does nothing) and especially pay attention to the green coloring of local variables and the gray coloring of the option string:

Mathematica graphics

After you have evaluated this, please press Ctrl+Shift+L to insert the output as new input.

Mathematica graphics

Do you see that all the code highlighting is gone (no green, no gray anymore)?

Btw, if you would have used the combination //InputForm//DisplayForm, then fully highlighted code is inserted by Shift+L.

With this in mind, would you please consider re-reading the detailed post here and rethink whether it should be marked a bug in your database?

Here is the answer from yesterday

This looks as a as-designed feature that's also explained in the documentation pages of InputForm and DisplayForm; InputForm prints all you need to be able to evaluate an expression (1D form) but DisplayForm prints also all the you need to show it as the front end would (2D form). However, I have passed along your comments/explanation to our developer team for further consideration.

I cannot say that I agree with this because (let's concentrate on this one) when I use Ctrl+Shift+L to insert the last output, you intend to use it as input and input should be properly highlighted. Beside, there is a major point: When I already created a new input cell by typing anything (for instance () and going inside the braces) and I use then Insert Output from Above, look what happens (especially pay attention that I used the evil InputForm):

Mathematica graphics


Consider the Cell generated using the InputForm wrapper:

a + b //InputForm

Cell["a + b", "Output", CellChangeTimes->{{3.747528582367461*^9, 3.747528588598588*^9}, 3.747528677164525*^9}, CellLabel->"Out[186]//InputForm="]

versus the Cell contents of the input "a+b"

Cell[BoxData[ RowBox[{"a", "+", "b"}]], "Input", CellChangeTimes->{{3.74752883542157*^9, 3.747528837893704*^9}}]

The key difference is that the InputForm output uses a string instead of a BoxData as the first argument. Since the argument is a string, 2D editing is disallowed, and because it is a string, syntax coloring doesn't work.

Using InputForm + DisplayForm as suggested by MrWizard produces a different kind of cell:

a + b //InputForm //DisplayForm

Cell[BoxData[ TagBox[ InterpretationBox[ StyleBox[ RowBox[{"a", " ", "+", " ", "b"}], ShowStringCharacters->True, NumberMarks->True], InputForm[\$CellContext`a + $CellContext`b], AutoDelete->True, Editable->True], DisplayForm]], "Output", CellChangeTimes->{3.747529163398923*^9}, CellLabel->"Out[190]//DisplayForm="]

Notice how the cell now contains a BoxData wrapper (as well as boxes, but that difference isn't relevant) with lots of wrappers. I don't like this approach because the boxes become rather unwieldy after 2D editing. For example, placing the cursor after the b and using Ctrl+6 produces the following cell:

Cell[BoxData[ TagBox[ RowBox[{ StyleBox["a", ShowStringCharacters->True, NumberMarks->True], StyleBox[" ", ShowStringCharacters->True, NumberMarks->True], StyleBox["+", ShowStringCharacters->True, NumberMarks->True], StyleBox[" ", ShowStringCharacters->True, NumberMarks->True], SuperscriptBox[ StyleBox["b", ShowStringCharacters->True, NumberMarks->True], "\[Placeholder]"]}], DisplayForm]], "Input", CellChangeTimes->{{3.747529388438327*^9, 3.747529388455496*^9}}]

Notice the proliferation of StyleBox wrappers that appears.

My suggestion is to create a new form that uses a TemplateBox, as this will prevent the proliferation of StyleBox wrappers:

MakeBoxes[myInputForm[expr_], StandardForm] ^:= With[
    {arg = MakeBoxes[InputForm[expr]][[1,1]]},
        DisplayFunction -> (StyleBox[#,ShowStringCharacters->True,NumberMarks->True]&),

myInputForm produces the following cell:

Hold[f[x_] := a + b] //myInputForm

Cell[BoxData[ TemplateBox[{"Hold[f[x_] := a + b]"}, "myInputForm", DisplayFunction->(StyleBox[#, ShowStringCharacters -> True, NumberMarks -> True]& ), InterpretationFunction->(#& )]], "Output", CellChangeTimes->{3.7475298985844793`*^9}, CellLabel->"Out[196]="]

If we place the cursor after the b this time, and use Ctrl+6 we get:

Cell[BoxData[ TemplateBox[{RowBox[{"Hold", "[", RowBox[{ RowBox[{"f", "[", "x_", "]"}], " ", ":=", " ", RowBox[{"a", " ", "+", " ", SuperscriptBox["b", "\[Placeholder]"]}]}], "]"}]}, "myInputForm", DisplayFunction->(StyleBox[#, ShowStringCharacters -> True, NumberMarks -> True]& ), InterpretationFunction->(#& )]], "Input", CellChangeTimes->{{3.7475300096828337`*^9, 3.747530009698186*^9}}]

Notice that the argument of the TemplateBox has changed from a string to boxes automatically, and the StyleBox proliferation we saw earlier is absent. Also, since we have a BoxData object, and the cell style has changed to "Input", the above cell has syntax coloring as desired. Here is a screen shot of the above rendered cell:

enter image description here


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.