I noticed in V 12.3, when trying to edit an expression in a cell, and moving/scrolling the mouse, the expression itself shakes. It seems to auto-resize or adjust while one is editing it.

This does not happen in V 12.2. Below are two small movies to show this. Here is some expression to try it on

ic = {M0[0] == 1, M1[1] == 2}

Let say one wants to edit it. Notice what happens when moving the mouse on it to scroll. it seems to shake/expand/shrink when the mouse is going over == in this example.

enter image description here

This is very annoying. Here is the same thing on V 12.2

enter image description here

You can see that there is no shaking.

I do not believe I am the first one to notice this as it is so obvious when I first started to use Mathematica today after I just installed it. Is there is a setting or some reason why it happens?

Window 10 professional. 64 bit.

  • 2
    $\begingroup$ @Moo Yes. Today. it is available in user portal. $\endgroup$
    – Nasser
    May 21, 2021 at 4:15
  • 9
    $\begingroup$ Try CurrentValue[$FrontEnd, {StyleHints, "OperatorRenderings"}] = {} $\endgroup$
    – ilian
    May 21, 2021 at 4:30

1 Answer 1


I think I understand the reason why it happens, but I'm not certain how to fix it, so this is more of an extended comment than an answer. The reason it happens is because rather than actually replacing things like -> with the right arrow character, it only renders that character in the front end now. When you move the cursor into the symbol, it temporarily suspends that rendering. According to the Wolfram blog this was necessary to deal with auto replacing of things like [[ into the double bracket. With the new system, they say you can delete just a single bracket without deleting the entire double bracket. Specifically:

It might seem odd that it’s taken so many years to go from “automatic →” to “automatic 〚 〛”. But it’s a lot more subtle than you might think, and in fact it’s required a whole new as-you-type approach to code rendering. Back in Version 3.0, the idea was to replace -> with → when you type it. So, for example, if you then backspace one character, you’ll delete the whole →, rather than simply “removing the >” and reverting to -.

But if you’re dealing with [[ ... ]] you can’t just do this kind of “local replacement” without the potential for confusion with some ]] showing up as 〛 while others break apart into ]] as a result of routine editing.

In Version 12.3 what we’re doing is not to make replacements at all, but instead just to render specified sequences of characters (like ]]) in special ways. The result is that we can support very general “ligature-like” behavior, and that backspacing will always exactly reverse characters that were entered.

This is apparently controlled by AutoOperatorRenderings which is an option for cells and notebooks. It says it's included in the Core.nb stylesheet. I've never really dealt with stylesheets, but it sounds like there may be someway to edit the default stylesheet to eliminate the AutoOperatorRenderings.


According to ilian and Jesse Friedman, the way to disable this function is CurrentValue[$FrontEnd, {StyleHints, "OperatorRenderings"}] = {}. I thought I would add this to my answer since it's only been in the comments so far.

  • 3
    $\begingroup$ This is correct (at least based on my experience of other text editors and ligatures etc). I believe you can modify AutoOperatorRenderings in the options inspector. $\endgroup$
    – Carl Lange
    May 21, 2021 at 8:03
  • 1
    $\begingroup$ The screenshot of the preferences window in the announcement blog shows the control for adjusting the DelimiterAutoMatching setting, not AutoOperatorRenderings. AutoOperatorRenderings can be disabled globally with CurrentValue[$FrontEnd, {StyleHints, "OperatorRenderings"}] = {}. (No, I don't know why the relevant option name is "OperatorRenderings" instead of "AutoOperatorRenderings" either.) $\endgroup$ May 21, 2021 at 19:09
  • 4
    $\begingroup$ AutoOperatorRenderings is implemented selectively on certain styles in the stylesheets. Because of the need to have that level of control, it's not possible to set it directly on $FrontEnd and have it be effective. So we're using StyleHints as a level of indirection. The places which want to set the full list of operator renderings in the stylesheet set AutoOperatorRenderings->Dynamic[AbsoluteCurrentValue[EvaluationCell[], {StyleHints, "OperatorRenderings"}]]. Then StyleHints can be set at any level at the cell or above, including on $FrontEnd. $\endgroup$
    – John Fultz
    May 22, 2021 at 2:00
  • 2
    $\begingroup$ @JohnFultz I really want to enable this feature for my v12.3 copy but I simply cannot get this feature. And I don't know where to debug. AbsoluteCurrentValue[ EvaluationCell[], {StyleHints, "OperatorRenderings"}] gives Inherited. $\endgroup$
    – sunt05
    May 23, 2021 at 10:40
  • 1
    $\begingroup$ StyleHints had been specified as a list in older versions, and didn't inherit properly for reasons which are unfixable without severely breaking backward compatibility. So StyleHints in 12.3 is now specified as an association, and the association spec would have worked in 12.2, but that wasn't the default there. This allows you to, e.g., set one key on $FrontEnd, and inherit the remainder from $DefaultFrontEnd. But a few people out there had set StyleHints before we made the switchover to associations, and so hard-coded the list. (1/2) $\endgroup$
    – John Fultz
    Sep 10, 2021 at 19:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.