42

Bug introduced in 10 and fixed in 12.1

Assume the following simple expression

{#"Test"}&

Now go in front of the # and just start typing another named slot expression. On my system, the front end invalidates the input by magically inserting invisible characters

Mathematica graphics

For a real cool demonstration, look at this

enter image description here

My system is: Mathematica 10.2 on Ubuntu 14.04

Update:

Official response of WRI confirms that it is a bug:

Thank you for taking the time to send in this report. It does appear that entering an additional string (quotation marks) is causing an issue with the front end's box structure, and I have forwarded an incident report to our developers with the information you provided.

Community
  • 1
halirutan
  • 112,764
  • 7
  • 263
  • 474
  • Do you think this is related to what happens here and in the question I linked in the comments? – march Sep 24 '15 at 03:23
  • I get exactly the same results with Mathematica 10.2 on Windows 7 x64. – WReach Sep 24 '15 at 03:34
  • 4
    Yes, I believe they are strongly related. What seems to happen is that when you open quotes and insert a string, the front end has to take the rest of your whole expression as string, because you haven't inserted the closing quotes yet. The moment you close the quotes, the front end rebuilds a wrong box-structure of your expression. This happens in my example and it happens in yours. You can easily verify this yourself. – halirutan Sep 24 '15 at 03:34
  • 1
    @march And if you don't know how to verify this, then just use a minimal example like this "a"(a )^2. Take one version that you copy and another version that you type by inserting the string at last. Then, look at both expressions by pressing Ctrl+Shift+E to show the box structure. You will see that the SupercriptBox does not contain the correct elements. – halirutan Sep 24 '15 at 03:40
  • 3
    Yes I see. Interestingly enough, as @MarcoB points out in that post, the formatted superscript is necessary for that example, which doesn't seem to be the case for yours. I've seen cases where the # will lose track of its corresponding & and turn pink when, for instance, I introduce new formatted fraction signs in an expression (although I'm having trouble reproducing that right now). Point being: it doesn't seem to be just quotes causing problems. I'll try my best to find an example... – march Sep 24 '15 at 03:49
  • Well, that last thing is actually a different beast, because it turns out that what I was talking about is not a formatting issue in the same way. As you can see here, sometimes it shows a pink Slot when really, under the hood (as shown using Ctrl+Shift+E), the formatting is correct: notice the FractionBox["#", "#"] in that example. – march Sep 24 '15 at 04:14
  • Versions of this problem have been present since the v10 betas. Some cases have been fixed, but problems remain in 10.2. I did report the problems during the beta, and more than once since then (including for 10.2). I run into this fairly often, I guess we just have to learn to live with it :P – Szabolcs Oct 01 '15 at 07:45
  • I would have thought something as basic as this would get properly fixed by the 4th 10-series release ... it's not just the display that's broken but also the boxes, they can't be evaluated anymore. – Szabolcs Oct 22 '15 at 14:55
  • What is the status of this bug in 10.3.1? – QuantumDot Dec 27 '15 at 11:49
  • Bug still present in V11.0.0 – mikado Aug 22 '16 at 18:36

0 Answers0