As we all know, when one is to send email with some Mathematica code in it, the practice is to do the following
Select the cell, Cell->ConvertTo -> INPUT FORM, then COPY AS TEXT
Then paste the code into the email, or any other exchange media it is.
The only problem with the above, is that when, on the other end, one copies the text from email and paste it back into a Mathematica notebook, the code will then no longer appear as it was in the original form (before the converting to INPUT FORM).
Because when one inserts the text copied from the email to Mathematica notebook, it becomes a standard form cell. All well, except the original code formatting is all lost.
Try it if you have not, convert a cell to INPUT FORM and the code will change shape, and I could not find a way to get back the original form before this operation.
Is there a way to email Mathematica code, in text of course, so that it keeps the same shape, and appear the same as it was originally when it was in standard form before the conversion?
Thanks
--Nasser
Cells formatted with the Code style (ALT/CMD-8) retain all formatting when using copy-and-paste. I use them all the time to format postings for SO. Well, truth be told, I use Code cells pretty much all the time, except for one-shot or throw-away input.
There are other advantages to using the Code style. It makes it easy to evaluate all of the definitions in a notebook, without also evaluating all of the incidental and test expressions: ALT/CMD-click on the cell bracket of any of the Code cells and then press SHIFT-ENTER. Also, Code cells automatically become initialization cells, which is frequently exactly what you want for the definitions in a notebook. Finally, when Mathematica spots Code cells in a notebook it offers to create an auto-save package that contains only those cells.
The downside to Code cells is that you lose the automatic formatting that Mathematica performs on cells with the Input style -- but then again that automatic formatting is precisely what we are trying to avoid in the context of this question.
Copying the cell as a cell expression doest the trick. Just right-click the cell bracket and the Copy as > Cell expression.
The resulting code is unusable for posting in newsgroups, as it is highly unreadable, but copying to and from email and back into Mathematica seems to preserve layout in the few tests that I did.
Since the problem is sending the code over email, why not just send (a part of) the notebook as an attachment. No copy-pasting mess, and guaranteed identical formatting.
Related
I have not done any MACOS programming in several years. However, I now need to test out some algorithms for formatting text as paragraphs. For these tests, I need to be able to display characters with absolute position control.
These tests need to determine where line breaks are to go within a paragraph and the amount of work spacing, while taking into account hyphenation, ligatures, page breaks, kerning and the like.
When I last did such things, I was using the text functions of the CGContext class. Upon returning from my hiatus, I find all of these function are marked "deprecated" in the documentation—which conveniently leaves out what the current acceptable replacement is.
What is the current, approved process for drawing single glyphs on Mac OS?
Functions that deal with formatting strings would defeat the purpose of the academic experiment here.
If I have the axis label $x_\textrm{ABC}$, the ABC is way too big. I tried $x_\textrm{\scriptsize ABC}$ and $x_\textrm{\tiny ABC}$, but that prevents the LaTeX code from being interpretted (I end up seeing the raw code instead of the formatted math). How does one shrink the subscript text size when the subscript is a name that needs to be spelled in text mode?
I posted this to usenet yesterday, but no response so far.
I also tried to modify the text in Acrobat Pro, but I can't actually highlight the individual series of characters (it's the y-axis label).
Finally, I tried to modify it in inkscape, but same problem.
A respondent at the usenet link provided the answer: To use \mathrm instead of \textrm. It looks way better.
Every now and then I run into a situation when I need to email a piece of code from emacs. When I paste text into my email program (not emacs), all the color highlighting is lost. This is especially disappointing when pasting from org-mode, which relies heavily on colors for readability. It would be good to preserve font faces.
Is there a way to do this? I am looking for output similar to that of ps-print-buffer-with-faces.
Suppose your email program can handle html, try M-xhtmlfontify-buffer, which converts the contents of the current buffer (with faces) to css-styled html.
Is there any description of a diff/patch format visualization algorithm? (or maybe it is too trivial to be described)
The Rietveld code review tool has a lot of comments explaining its operation in its source code. Take particular notice of intra_regiion_diff.py and engine.py.
What diff tools produce as data is pretty basic: "this line changed that way".
"Visualizing" that normally consists of showing the original code and the modified code side by side, with the "this line changed" indicated by marking the display text somehow. Basically this means scrollable text windows with painted stripes of text. Fancy versions will paint lines between the changed line in one window, and it corresponding line in another.
Mathematica offers the Notation package to define custom notation, and it seems to work great until I save a notebook with custom notation as a package and try to use Needs["..."] to import the new notation. As documented on the Mathematica mailing list, this causes bizarre syntax errors when evaluating any call to Notation[]. The suggested solution is to manually open the notation notebook and evaluate it into the kernel, but this is a pain for files that I plan on distributing. If anyone has a better workaround for the problem, I'd really appreciate the help!
I think your problem lies in the way Mathematica treats Notation[], quote:
When defining your own notations it is
critically important to use the
notation templates. The reason for
this restriction is that the templates
pasted into a notebook contain
essential tag boxes embedded in the
correct way.
It may not be possible at all to have a package file call Notation[], but there is a suggestion of using ParsedBoxWrapper which I didn't have time to play around with right now.
There is a kludgy solution to your problem, which is that you put all the Notation[] assignments into one cell of the Notebook and make it an initialization cell (right click on the cell edge --> Initalization Cell). This will incidentally also create a .m file with just the contents of that cell (but this file will, alas, not work with Needs[] or <<). After that you can collapse the cell, make it uneditable, unevaluatable, and hey presto! Almost like what you want.
I should note that from a distribution point of view this kludge is rather nice since the .m file gets regenerated every time you load the main file so you don't need to ship multiple files. The only downside is a slightly ugly Notebook (i.e. one hidden cell), and a pop up asking whether you want to evaluate the initialization cells of the Notebook whenever you first evaluate something in that Notebook.