5

Bug introduced in 10.0 and persisting through 11.0.1 or later

Starting from Mathematica 10, there's a new feature: when you begin editing your input cell, its output becomes faded. A side effect of it is that in certain cases the output is dynamically updated. This results in annoyances like when you e.g. have made a mistake leading to messages being emitted and now try to edit the input cell to fix the mistake.

Here's a simple example:

Manipulate[ListPlot[Table[Sin[a x]/(a x), {x, -10, 10}], Joined -> True], {a, -10, 10}]

(manipulator here)

Power::infy: Infinite expression 1/0 encountered.

Infinity::indet: Indeterminate expression 0 ComplexInfinity encountered.

Now try e.g. to replace Sin[a x]/(a x) with Sinc[a x], and you'll get two more identical messages. In more complicated scenarios the manipulator may spit lots of messages, which you may have stopped by e.g. Alt+.. But once you start editing the input cell, all they will be emitted again.

This does not happen with every input. It happens with Manipulates that contain contain plotting functions in their code (even if the plot output is never displayed).

So my question is: how do I disable this (mis)feature of fading the output on editing input?

Michael E2
  • 235,386
  • 17
  • 334
  • 747
Ruslan
  • 7,152
  • 1
  • 23
  • 52
  • Could you not delete the output cell before you begin editing the input cell? – Edmund Oct 30 '16 at 12:53
  • The output doesn't get re-evaluated. Dynamic updating is triggered for some reason in this Manipulate (but not in general). Perhaps you can update the title and description to avoid any confusion. – Szabolcs Oct 30 '16 at 12:56
  • I've reported this when it first happened, FWIW. – Michael E2 Oct 30 '16 at 12:56
  • @MichaelE2 Do you understand what is happening? There's no general re-evaluation (that would be a disaster). Not all Dynamic stuff gets updates (simple examples don't). Manipulate is a bit special in that it doesn't actually evaluate, it just formats in a special way (MakeBoxes). I tested and MakeBoxes are not called a second time when the output is faded. What happens then? – Szabolcs Oct 30 '16 at 13:01
  • Without the ListPlot it doesn't even happen. Can't reproduce with simpler Manipulates. – Szabolcs Oct 30 '16 at 13:05
  • Here's a simpler example: Manipulate[ Print["Evaluating"]; ListPlot[{1, 2}]; a, {a, -10, 10}, TrackedSymbols -> {} ]. The ListPlot is critical, without it this doesn't happen. – Szabolcs Oct 30 '16 at 13:09
  • @Szabolcs I'm not sure how I should change the title. I've seen a similar problem with Plot3D output, which on my slow i915-like GPU with ugly Mesa drivers appears to hang for some time again (as if it's re-generated) when I start editing the cell which generated it. So this all looks like a re-evaluation to me. Feel free to edit the title if you know how to formulate it correctly. – Ruslan Oct 30 '16 at 13:10
  • I think what really happens is a "re-formatting" (i.e. invocation of MakeBoxes), but I'm not sure yet. E.g. select the output cell and press control-shift-N to convert to StandardForm (even if it is already StandardForm). I suspect this is what really happens. – Szabolcs Oct 30 '16 at 13:12
  • There's also the weird thing that in my example in the comment above, Print will print to the notebook directly. However, if I remove ListPlot, it will print to the message window for some reason. Manipulate appears to switch to a different mode when it detects the ListPlot inside. Maybe this has to do with $ControlActiveSetting, not sure. – Szabolcs Oct 30 '16 at 13:13
  • @Szabolcs No, I don't know exactly what's happening. As you noticed, it seems to have to do with plotting (maybe exclusively). There are dynamically tracked variables with *Plot[] output, and something that gets changed when the output cell is dimmed must affect one of these variables and triggers an update. – Michael E2 Oct 30 '16 at 13:14
  • @MichaelE2 Here's something weird: Manipulate[x; Print@$PerformanceGoal, {x, 0, 1}] When the control is active, this should be Speed. That gets printed in the messages window. When the control stops being active, it reverts to Quality. That is printed within the notebook itself. This whole thing must have something to do with the detection of when quality must be reduced during changing the controls. Usually this is necessary only when there are plotting functions. – Szabolcs Oct 30 '16 at 13:20
  • Some more progress: whether something gets printed in the notebook or in the messages windows depends on the SynchronousUpdating setting of Manipulate. True prints in the messages window. The default Automatic setting switches depending on whether controls are active. This is why we see alternate printing in the notebook/messages window. – Szabolcs Oct 30 '16 at 13:26
  • @Szabolcs The switch between output notebooks makes sense, since it's really hard to manipulate controls if the notebook is constantly being re-typeset. -- I think this will be hard to track down because the variable(s) that are changed when the output cell is dimmed are probably maintained internally by the FE. My LinkSnooper is broken, or I would look at that. – Michael E2 Oct 30 '16 at 13:34
  • More progress: My initial hunch that what really happens is re-formatting was incorrect. It is a simple dynamic updating without re-formatting (re-running MakeBoxes). This is my conclusion after setting Manipulate`Dump`DebugPrint = Print and trying editing the input, and also trying re-formatting through ctrl-shift-N. Only re-formatting triggers debug messages. – Szabolcs Oct 30 '16 at 13:39
  • I give up. I don't know. – Szabolcs Oct 30 '16 at 13:51
  • Somewhat related: http://mathematica.stackexchange.com/questions/73489/resizing-or-moving-notebook-window-causes-manipulate-to-update-its-argument – Michael E2 Oct 30 '16 at 15:08

1 Answers1

3

Here is a workaround, unless you like plot themes: PlotTheme -> None.

n = 0;
Dynamic[n]

Manipulate[
 1/x; 
 ++n;
 Plot[Sin[n t], {t, 0, Pi}, PlotTheme -> None],
 {x, 0, 1}, TrackedSymbols :> {x}]

I reported this in October, 2014 (CASE:1866485). One of the developers said he thought it had to do with a dependency related to plot themes being set that shouldn't be. That gave me the idea for the workaround above.

One can also set $PlotTheme = None as a workaround. If the Manipulate has already been executed, a new $PlotTheme will not take effect until after the next time Manipulate updates the plot.

$PlotTheme = None;  (* execute after Manipulate to see it work after the fact *)

Manipulate[1/x;
 ListPlot@Table[Sin[(1 + x) t]^2, {t, 0, 10}],
 {x, 0, 1}, TrackedSymbols :> {x}]
Michael E2
  • 235,386
  • 17
  • 334
  • 747