<blockquote>
<p>As for changing the API, the usual solution would be to add the new parameter and provide a default argument for it (and the default would be the "normal" behaviour, so other plugins don't even notice that there is something new). If I am not mistaken, Geany is implemented in C, and C doesn't have the feature of default arguments builtin, but there are several ways to achieve this functionality in C too.</p>
</blockquote>

<p>Yes, C++ overloaded functions would be a nice alternative too, but unfortunately ....</p>

<blockquote>
<p>so IMO, the best (and maybe easiest) way would be to extend the API.</p>
</blockquote>

<p>So long as one of the options of the new API matches the semantics of the old API then the old API could just call the new one with the appropriate options.  There is a common idiom of having something like "save", "save_2", "save_3" etc when new interfaces are needed and the old one is to be left unchanged.</p>

<p>The thing is to design an API and semantics that minimises the risk of introducing bugs in the normal save operations.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br>Reply to this email directly or <a href="https://github.com/geany/geany/issues/815#issuecomment-165039486">view it on GitHub</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/ABDrJ_vV559W5XEPMlJ7nzVFIz-jBuj1ks5pQSD2gaJpZM4G04_e.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/geany/geany/issues/815#issuecomment-165039486"></link>
  <meta itemprop="name" content="View Issue"></meta>
</div>
<meta itemprop="description" content="View this Issue on GitHub"></meta>
</div>