I have seen a number of example that use \patchcmd from the etoolbox package. I am not too familiar with this package and wanted to understand what would be the appropriate situation to use \patchcmd instead of renewcommand.
My use-case involves changing the definition of \maketitle in the KOMA-Script package to give me greater control on the individual pages comprising the frontmatter.
There is no hard-and-fast rule. There are cases where \patchcmd won't work, but you can always use one of the more sophisticated patching options in that case.
Generally, if you want to design what \maketitle does from scratch, use \renewcommand; if you want to adjust what \maketitle does, use \patchcmd.
It is the difference between knocking down a house in order to build a new one and extending or modifying an existing house. There are borderline cases, but if you just want a wooden door rather than a plastic one, modification is the better option; if you want to add a basement swimming pool and turn a 1 room shack into a 3 storey mansion, then rebuilding from scratch makes more sense.
If you would start to build your command by copying the code from KOMA in order to edit it, there's a good chance patching may make sense. If you would start to build your command by just writing code to do something different, patching is unlikely to make much sense.
The real advantage of patching is that you'll benefit from updates to the original. One disadvantage, of course, is that the update may break your patch. But you probably want to know in this case anyway, as other, less obvious, complications may follow.
Problems are easier to track down and identify if good use is made of the final two arguments of \patchcmd.
\patchcmd{<macro name>}
{<to be replaced>}
{<replacement>}
{\typeout{Patching of <macro name without backslash> succeeded.}}
{\typeout{Patching of <macro name without backslash> failed.}}
This allows you to scrutinise the console output or .log file for relevant lines, enabling you to check whether the patch was successful or not. You can also assess the patching process (and success or failure) by adding \tracingpatches to your preamble after loading the package.
\tracingpatches suggestion but I've never used it and was too tired to look it up right away, so thought I'd come back to it.
– cfr
Aug 21 '16 at 13:31
\patchcmdfor the title with a KOMA-class isn't a very good idea, imho. Userenewcommandto redefine the title If you need this more than once. If you need it just once, don't waste time in patching and redefining, do the page(s) from scratch. Please see How to customize my titlepage? – Johannes_B Aug 21 '16 at 05:23\maketitledoes a lot more in e.g. the case of books, for example. But only if patching is appropriate in the first place, of course, and the one-offness is definitely a good point. – cfr Aug 21 '16 at 13:38sectionmarkin case you want to patch that. – Johannes_B Aug 21 '16 at 13:47\patchcmddoes - I love the analogy to house renovation.@Johannes_B also pointed out very helpfully the right way to go for the titlepage and pointer to an extremely helpful question on SE. His comments on the intricacies of KOMA-script and the difficulty of finding code to patch is very apt.
– SACHIN GARG Aug 22 '16 at 03:09\maketitlemacro. Any pointers on how can I start doing that in the context of KOMA-Script? In http://tex.stackexchange.com/a/210280/42648 you do point out a way to do it with KOMA-script using thetitlepagepackage. Any pointers on how to get my own style intitlepageor would I be better off starting from scratch? – SACHIN GARG Aug 22 '16 at 03:17