Bug fixed in 12.0
I've long been peeved that the front end scrolls automatically during evaluations, and I've finally sat down to pin down the exact behavior.
It seems that the front end auto-scrolls whenever printing occurs with the input cell offscreen. I'm inclined to think this behavior is a bug, because it doesn't seem helpful in any way -- the auto-scrolling never seems to improve one's view of the output or anything else.
Of course a workaround is to avoid printing, but it's just so convenient for displaying information about the evaluation that doesn't need to be accessed later (e.g., the time taken in AbsoluteTiming
). Also, I use packages that print some information (version info, etc) upon loading, and often reload them (as initialization cells) as part of my workflow. (This is what made me sufficiently annoyed to investigate further.) To be clear: I like these messages, and I do not find some way of turning them off to be a satisfying workaround.
I'm still not entirely sure what the exact behavior is
- Sometimes the behavior seems well-defined
- If the input cell and printing area is entirely in view, do not auto-scroll
- If the input cell or printing area (location on the screen where the printing will show up) is only partially in view, scroll so that more of the printing area is in view
- I suspect this might be the intended behavior, but it is broken for other cases
- If the printing area is partially in view (but the input cell is not), auto-scroll to the top of the printing area
- If the current view is entirely below the printing area, scroll to the bottom of the output cell
- This seems to fail if the current view is 'too far' below the output cell, though I haven't been able to quantify this
- Sometimes the behavior seems less defined (particularly in a very long notebook when the current view is far away from the evaluated cell)
- When in doubt, evaluate a long notebook first (so the notebook is significantly larger than the view on a single screen), and then check this behavior again
A few things to note:
- The auto-scrolling is the same when
Echo
is used rather thanPrint
. - I noticed this first for initialization cells, but the same thing seems to happen for all cells
EvaluationCompletionAction
is globally set to{}
- I double checked that my initialization cells have the same
EvaluationComplettionAction
set - lol at
EvaluationCompletionAction
being introduced in V4 and still not "fully integrated into the long-term Wolfram Language"
- I double checked that my initialization cells have the same
- Another question (116047) seems to ask the same question, but was closed when workaround (
Monitor
rather thanPrint
) was introduced.- Again, I like the look and persistence of printed output, and any workaround would have to mimic the behavior and look of
Print
'ed output fairly well
- Again, I like the look and persistence of printed output, and any workaround would have to mimic the behavior and look of
- Here's a Dropbox link to a notebook which should reproduce the problem
- Just put the cursor inside one of the
Do[Print[...
input cells, scroll down so that input cell and printing area is no longer in view (the further down you scroll, the better), and pressShift-Enter
to evaluate the cell. You should see the notebook scroll (at least a little bit) and then stop somewhere seemingly arbitrary
- Just put the cursor inside one of the
- I'm using
$Version
"11.2.0 for Microsoft Windows (64-bit) (September 11, 2017)"
on Windows 10
Is there any way to Print
without suffering form auto-scrolling in the front end?
Do[Pause[.5]; Print[1], 100]
. As for the "not integrated fully" note, most front-end options say that, but until the FE is completely rewritten (which supposedly is coming) they're probably here to stay. $\endgroup$