<blockquote>
<p>design must allow progressive implementation [...] The intention is to design a mechanism so that no more language specific branches need get added to Geany core. But unless the process of including plugin capability in place of the built-ins can proceed in small chunks it probably isn't going to happen at all, simply due to resource availability.</p>
</blockquote>
<p>Couldn't agree more, so I'd say let's staple this approach as the way to go.</p>
<blockquote>
<p>Certainly, if anyone wants to chime in with their knowledge (or investigations) of existing editors that will be useful and may be adaptable to Geany.</p>
</blockquote>
<p>I will check around and report back if I find anything comparable/useful.</p>
<blockquote>
<p>Plugins are part of the Geany process and address space, so if they crash or hang so does Geany, thats an unfortunate fact of life. It is very unlikely that will change so plugin devs just have to be careful.</p>
</blockquote>
<p>Yeah, this is a too fundamental aspect of Geany and I would not even think of changing it in any way (IMO it is the basis of being "Lite" and fast too). However, the moment a corpus of new plugins emerges (external or official) we might want to define testsuites to catch rogue plugin behavior situations and not necessarily at UI-level as I was hinting in <a href="https://github.com/geany/geany/issues/1462" class="issue-link js-issue-link" data-url="https://github.com/geany/geany/issues/1462" data-id="220385850" data-error-text="Failed to load issue title" data-permission-text="Issue title is private">#1462</a>.</p>
<p>The reason I am mentioning this is - from my tiny experience with <a href="https://github.com/geany/geany/pull/1457" class="issue-link js-issue-link" data-url="https://github.com/geany/geany/issues/1457" data-id="219414565" data-error-text="Failed to load issue title" data-permission-text="Issue title is private">#1457</a> - that the moment I coded a synchronous call to an external command I knew a "sin" was being done, in the sense that potentially  Geany would become stuck when the external process becomes rogue. And as you said, no safeguard would be in place for this even with the plugins system.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/geany/geany/issues/1458#issuecomment-292708259">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ABDrJ0V7r62jaPuqzCMiPKrXspzy44teks5rt1ydgaJpZM4M1Ajm">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/ABDrJ2-f6utNbIH-Vxg26oeCo9Cxxuoxks5rt1ydgaJpZM4M1Ajm.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/1458#issuecomment-292708259"></link>
  <meta itemprop="name" content="View Issue"></meta>
</div>
<meta itemprop="description" content="View this Issue on GitHub"></meta>
</div>

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/geany/geany","title":"geany/geany","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/geany/geany"}},"updates":{"snippets":[{"icon":"PERSON","message":"@gdm85 in #1458: \u003e design must allow progressive implementation [...] The intention is to design a mechanism so that no more language specific branches need get added to Geany core. But unless the process of including plugin capability in place of the built-ins can proceed in small chunks it probably isn't going to happen at all, simply due to resource availability.\r\n\u003e \r\nCouldn't agree more, so I'd say let's staple this approach as the way to go.\r\n\r\n\u003e Certainly, if anyone wants to chime in with their knowledge (or investigations) of existing editors that will be useful and may be adaptable to Geany.\r\n\u003e \r\nI will check around and report back if I find anything comparable/useful.\r\n\r\n\u003e Plugins are part of the Geany process and address space, so if they crash or hang so does Geany, thats an unfortunate fact of life. It is very unlikely that will change so plugin devs just have to be careful.\r\n\u003e \r\nYeah, this is a too fundamental aspect of Geany and I would not even think of changing it in any way (IMO it is the basis of being \"Lite\" and fast too). However, the moment a corpus of new plugins emerges (external or official) we might want to define testsuites to catch rogue plugin behavior situations and not necessarily at UI-level as I was hinting in #1462.\r\n\r\nThe reason I am mentioning this is - from my tiny experience with #1457 - that the moment I coded a synchronous call to an external command I knew a \"sin\" was being done, in the sense that potentially  Geany would become stuck when the external process becomes rogue. And as you said, no safeguard would be in place for this even with the plugins system."}],"action":{"name":"View Issue","url":"https://github.com/geany/geany/issues/1458#issuecomment-292708259"}}}</script>