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.
Related
A student in another class coloured their code in their word document, I asked my teacher if he knew how and he suggested he coloured it all by hand... I'm very sure he didn't colour hundreds of lines of code by hand.
I've also seen many websites that colour the code snippets to help with readability - including StackOverflow!
Here's a print screen of the code contained in the word document.
as you can see they're not print-screens as not only can I highlight the text, word has underlined what it thinks are errors in spelling / grammar.
When you copy-paste into a Word document, it (by default) retains the formatting of the text copied into it. IDEs (e.g., Visual Studio, Eclipse, IntelliJ, etc.) usually perform syntax highlighting (i.e., color different elements of the code differently in order to highlight their purpose) for you. If you copy and paste from the IDE you've used to create the code, it will probably retain this formatting.
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.
While in class I like to take handwritten notes, afterwards I scan them and then type them up (helps me remember them and also makes them easily searchable). The main issue is I have is I use A LOT of drawings and complex math and converting the math formulas into latex (or word) is very time consuming and the drawings require that I keep the PDF and the text document. What I would like to do is take the basic text that I have typed myself (no OCR) and add a text layer to the PDF's that way the PDF's will be searchable and I can save a lot of time by not converting the math or drawings.
I've looked into Preview, PDFpenPro, acrobat, a couple of linux programs but so far I haven't really found anything that will do this.
Any idea of how I could do this or a program to use?
I also scan my notes. Sometimes I go back and add some text to them using this technique:
Open up the scanned pdf in Preview, then click on the "Edit" button in the top right corner, then the "Text tools" button on the left side (its a little box with Aa in it). From there you can drag open a text box and type into it.
Now the secret trick is that if you save it here as it is and try to open it in your ipad using PDFExpert or some other program then the text might not be there. So here's how to go through that slight hiccup: After you've annotated your notes how you want instead of just saving it as a pdf, use the Print option: File->Print or Command+P. Now click the PDF button on the left to "Save it as a pdf". Now that its printed you can open it and search it in any program that reads pdfs. Attached is an example.
One other thing, it seems like maybe you want to write over your existing handwritten text with typed text? I'm not sure if this is the best way. But if that's what I was trying to do I would:
Scan my notes
Read through them, typing them up as you said
Open the scanned notes in Photoshop or some other program
Draw a giant White Fill White Stroke rectangle over the handwritten text
Save it as a pdf
Do the technique above and copy and paste the typed text from step 2.
I hope this helps. And I wish you luck, I'm still working out the kinks myself for scanned notes but the possibilities have me pretty excited!
EDIT: I just checked out PDFpenPro, which I highly recommend because you don't have to go through that printing trick, you can just save the pdf document after annotating and other programs will recognize the annotations.
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.
I am in the process of writing a text editor. After looking at other text editors I have noticed that a number of them refer to a "soft" versus "hard" wrap. What is the difference? I can't seem to find the answer by searching.
A hard wrap inserts actual line breaks in the text at wrap points, with soft wrapping the actual text is still on the same line but looks like it's divided into several lines.
It's usual for text editors to auto-wrap text into paragraphs with hard newlines, but it's less common for the text to be re-flowed into a nice paragraph if you come back later and edit/add/remove words later on. (You can do this manually in emacs with M-q.)
This is rather annoying, since obsessive compulsive people like me then go back and have to manually re-insert the hard breaks at the appropriate points.
On the other hand, soft wrapping is annoying because most all command line tools use line-based diff-ing (version control is where this becomes most noticeable to me). If you've got a 1/3-page paragraph that's soft wrapped and fix a typo, it's basically impossible to see where the change is in a regular diff output or similar.
soft : The text in the textarea is not wrapped when submitted in a form. This is default
hard : The text in the textarea is wrapped (contains newlines) when submitted in a form. When "hard" is used, the cols attribute must be specified
Reference: W3Schools