The undocumented System`Dump`showStringDiff function neatly does the diff and highlights it for you. The simplest usage is:
You can choose custom colours for the highlights with the Styles option. You can also change the background, font weight, add a...
@JohnFultz We were discussing the following: Especially you leak from time to time very, very usefull undocumented functions. If this does not conflict with your Wolfram NDA, wouldn't it be possible to give us some hints whether there is a way to, let's call it explore undocumented stuff ourselves?
@halirutan, well working for WRI for 19 years comes with some privileges. :) But there are some real issues with some of the undocumented stuff. My biggest concern is that some of it isn't very well designed. Either we might replace it later with something much better designed, or it might be functionality which is prone to crashing because it doesn't have very good error-handling.
For example, right now, we're looking at shipping some functionality in v9 which will enable background images in notebooks (which would answer one of the unanswered SE questions, I noticed last night). Enough functionality is turned on to use in slide shows, and it'll be really neat. The problem is, it was introduced late enough that the design was not vetted, and I already know the design is not up to usual Wolfram standards. So, what to do?
We could not ship the slideshow functionality. We could lock ourselves into a bad design. We could delay v9 to fix up the design. Or we could go ahead and use it internally now, but knowing that users will really want to do this themselves, we'll plan to fix up the design in the future. From my perspective (yours may differ), the last option looks good.
yes, I see the point. But in the case of the tokenizer for Input-cells I tried every possible thing.. Especially to keep the non-semantic whitespaces and then BOOM, you come and solve everything with one answer.
Concerning the UndocumentedTestFEParser packet, that was actually added for QA purposes. It makes adding a test harness easier. I guess I wasn't imaginative enough to consider that real-world users would be seriously interested in this. My bad.
@JohnFultz And basically, I'm aware that those things maybe introduce bugs but it's better than having nothing. And as I said to @Rojo, it's not that I want to write long-lasting software I want to sell..
Thanks a lot, let's see :). Also there's one old question that I believe you might know something very simple that would help a huge lot. It's about programatically getting some current counter value at the place where it is executed. mathematica.stackexchange.com/q/6073/109
But, something you should understand about packets. You can really mess up a front end if you send bad stuff through to the packets. The bar for input validation isn't as high, and in the worst case scenario, it's not too difficult to crash the FE or to mess up the MathLink connection between FE and kernel.
BTW, I saw on the chat session yesterday some confusion about stuff in the FrontEnd` context. As some have guessed, the FrontEnd` context is generally (can't remember if it's exclusively) used as an inert context. So, for example, look at EvaluationNotebook:
The FE packet has the same name as the kernel symbol. But we can't have it evaluating out from underneath us, and it's stupid to give it a different name. So the FrontEnd` context is a totally inert version in the kernel.
@halirutan, the crazy thing is that you must be like the 20th person or so to have done this. At one point, I suggested that we release a YACC grammar for CDF (which would be a significant subset of the Mathematica grammar), but the idea wasn't well received by various parties.
Internally, I can think of at least six notebook parsers running around (I wrote three of them!). :) And then the full Mathematica grammar is implemented, separately, in both FE and kernel, as well as various syntax coloring engines (yours is far from the first, but I think it's the only contemporary one besides the one in Workbench).
@halirutan I think there are two issues here. One is the level of effort required. Constructing and maintaining an AST is non-zero effort on our part. And the grammar as implemented in the FE and kernel are tightly integrated...very difficult to extract. Fortunately, we're at least documenting precedences, so most of it could be reconstructed, but painfully, I'm sure.
Second is the concern about whether we're giving something away that could reduce our competitive advantage. I personally don't think too hard about the second issue, but other people do (and, yeah, it'd be kind of irksome if some open-source competitor adopted code we produced purely for purposes of making their product look better when compared to ours).
But the good news is that, as announced at the WTC, we're now beginning to put stuff on GitHub (first project, HadoopLink). When time permits, I should ping folks again about this sort of activity.
BTW, I saw some talk on here about sniffing traffic between the FE and kernel. Are you folks using LinkSnooper? Or do you even know such a thing exists? We use it all the time internally, but I'm not sure how much it's been discussed externally.