evaluation - Understanding Villegas-Gayley

Temporary message: I have written another question about the behaviour the code by Oleksandr R. . Sadly I clicked "discard" and that was lost. I am a bit demotivated now and in order to not let the work pile up I chosen the least juicy part of the question to be the new shortened version. Retract your upvote if you will.

In this nice answer, Mr.Wizard writes

mk : MakeBoxes[(Hold | HoldForm | HoldComplete | HoldPattern)[__], _] :=
  Block[{$hldGfx = True, Graphics, Graphics3D}, mk] /; ! TrueQ[$hldGfx]

which is an application of the Villegas-Gayley pattern

Question: How does the Villegas-Gayley pattern work?

Answer

Say there's a function with only DownValues (as an example). The objective is to inject some wrapper code to it. You want to replace the function definition with your own code, but allowing your own code to call the unmodified function. For example, you might want to add preprocessing or postprocessing. All this, without requiring to modify existing definitions, either because of style or because of a real limitation as in the case of system functions. This is where the trick comes in.

How to do it

You need to prepend a definition that only matches when a variable is in a certain state. Then, while inside your function, you dynamically localize that variable so that it doesn't match the definition. Many built-ins whose definitions you can't access, will always try your custom definitions first so you might not need to worry about "prepending" the values. Example

Unprotect[Expand];
warn = True;
p_Expand /; warn /; ChoiceDialog["Sure?"] := Block[{warn = False},
   Print@"I'm about to expand";
   With[{exp = p},
    Print@"I expanded, here you go";
    exp
   ]
 ]

In this last case, the variable warn acts as a guard that you can modify to turn this definition on and off, in case you are interested. Otherwise, for safety, it may make sense to localize it and make it unique, for example, with a Module, as in

Module[{guard=True},
    fun[_]/;guard:=Block[{guard=False}, code] 
]

It seems the original version of the trick was intended to inject code in built-in functions. These functions live in the System` context. Your definition will also live in that context, since it is attached to the unprotected system symbol. As @Mr.Wizard warned in the comments, there's an evil lurking: the chance of Clear["Global`*"]. If your guard symbol lives in this context, then you will have a problem after clearing it. A solution that gets the best of both worlds is then

Module[{inside},
    fun[_]/;!TrueQ[inside]:=Block[{inside=True}, code] 
]

For those cases where the function returns unevaluated, you fortunately have the "cache bug" to prevent an infinite iteration. I don't think this "bug" is going anywhere, since this trick is used internally by Wolfram, and Update is a documented function.