Output code not highlighted when used as input

Question

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

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:

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.

Answer 1

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:

Needs["GeneralUtilities`"]

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

Answer 2

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.

Answer 3

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]

---

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:

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

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):

Answer 4

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]]},
    TemplateBox[{arg},
        "myInputForm",
        DisplayFunction -> (StyleBox[#,ShowStringCharacters->True,NumberMarks->True]&),
        InterpretationFunction->(#&)
    ]
]

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: