# On Reverting Code that Mma Switches to Raw Input Form Back to Standard Form

I experienced a similar issue to what is described in this post while editing formatted usage messages (that contained italics) in the declaration section of a package that I'm developing in the notebook front-end.

Question 1: Does anyone know what exactly causes Mma to convert code that contains formatted text to raw input form without explicitly being requested to do so by the user? Is this behavior part of a feature that several of us apparently do not fully understand ... or does it represent a bug in the parser that Wolfram acknowledges?

The solution described in the post linked above did not quite solve my problem because I need to evaluate the sequence of usage messages as part of setting up the package. I eventually found that

FrontEndExecute@FrontEndCellPrint["myFunction::usage=\"myFunction does ...\";"]


recovered the cell with usage messages displayed in standard input form exactly as I originally entered them (i.e. no explicit Styleboxes and escaping of quotes etc.).

In the process I reviewed the documentation on CellPrint and its FrontEnd-equivalent version. The main difference from what I could gather is that the former is handled by the kernel while the latter is processed solely in the FrontEnd. While experimenting with the two versions of CellPrint, I noticed the following:

CellPrint[Cell["a", "Input"]]


produces the cell expression

Cell["a", "Input"]


whereas

FrontEndExecute@FrontEndCellPrint["a"]


produces a BoxData-wrapped version of the above

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


One obvious consequence of this discrepancy is that the syntax highlighter colors the latter in blue but not the former.

Question 2: Why does the version of CellPrint evaluated in the kernel not wrap the input text in a BoxData structure too?

While my issue with the auto-conversion of usage messages to raw input form is now resolved I feel that my understanding from reading the documentation of how Mma parses and produces different formatting structures is still far from complete. Perhaps an answer here will shed additional light on this topic.

-

The simple answer is, if you want a string converted to StandardForm, you could wrap BoxData around it. E.g.,

CellPrint[Cell[BoxData["myFunction::usage=\"myFunction does ...\";"], "Input"]]


But, in general, I wouldn't structure this as a question of CellPrint vs. FrontEndCellPrint. FrontEndCellPrint is undocumented, and therefore there is no contract with the user that it will perform in any given way or that it will not change in the future. And, given that FrontEndCellPrint exists primarily as a vehicle for implementing CellPrint, I frankly can't even give any private assurances or documentation about its behavior that I would consider robust and future-proof.

Also, CellPrint may not be what you want in the first place. CellPrint is great for cells which become part of the output group. It generates "output-like" cells which will be automatically replaced upon the next re-evaluation. E.g., CellPrint[Cell[ToString[RandomReal[]], "Message"]]. You're creating an Input cell, which doesn't get regenerated because of the way that the cell groups are structured, but that begs the question...do you really want the Input cell to always appear (and be duplicated upon multiple evaluations) immediately after your code with CellPrint?

I would consider using NotebookWrite here (perhaps in combination with SelectionMove) here. NotebookWrite has some advantages I think you'll find useful:

• You can write anywhere you want to, even in a different notebook
• If you like, you can write code that deletes and replaces previously generated cells (using, e.g., NotebookFind and NotebookDelete)
• NotebookWrite allows you to write into cells in place rather than creating them from scratch.
• If you give NotebookWrite a string, the characters will be pasted in the same style as if the user had just begun typing those characters.

It should be mentioned that Paste has similar advantages to NotebookWrite.

The BoxData trick I mentioned before works with NotebookWrite, of course.

NotebookWrite[NotebookCreate[], BoxData["f[\"string\"]"]]


But it's not necessary to create a default, StandardForm Input cell.

NotebookWrite[NotebookCreate[], "f[\"string\"]"]
`

Does the same thing because this is what you would have gotten if you'd literally typed the characters of the string into the new notebook.

-
This question could use your attention, if you please. –  Mr.Wizard Apr 14 '13 at 20:16
@Fultz: Thanks for the detailed response ... especially the point about commands in the FrontEnd context not really being intended for end-users. (Not clear from this section of the documentation.) Agree that NotebookWrite would be preferable for many applications -- my goal here was simply to convert some code that contained italics, which had mysteriously flipped into raw input form, back to standard input form. Do you have any additional insights in to what causes this behavior in the front-end? –  StackExchanger Apr 17 '13 at 5:34
The package editor is going to tend to do this. The possibilities...if you don't have to edit the package, then the code should still work (produce a styled message when evaluated). Or work in a notebook file and Save As->Package file to export, but use the notebook as the main way of storing your source code. Or use auto-generated packages, which are turned off by default in v9, but can be turned back on using the AutoGeneratedPackage option in the option inspector. –  John Fultz Apr 22 '13 at 23:30
@Fultz: I use the auto-generate package mechanism and always edit the notebook file (hardly ever looking at the .m package file and certainly not editing it). It's probably worth emphasizing here that this behavior can occur while editing in the notebook front-end. –  StackExchanger Apr 28 '13 at 8:13
@Fultz: A somewhat related issue that has caused me additional grief on occasion concerns how style boxes are created when moving back and forth between plain text and italic in code cells where I'm using formatted text to define usage messages. Extraneous style boxes (containing no text) can sometimes be found littered throughout the underlying cell expression. Sometimes bizarre and difficult to track down parsing errors are reported by Mma while trying to load a package. –  StackExchanger Apr 28 '13 at 8:17