Am 09.07.2015 um 04:41 schrieb Matthew Brush:
On 2015-07-08 07:28 PM, Steve wrote:
I agree. Maybe a reload_plugin type function? I saw a similar
problem in gedit plugins, where you have to restart the editor for
some things to take effect. And you're right, if i remember
correctly, I just
Am 09.07.2015 um 04:28 schrieb Steve:
On Jul 8, 2015 7:18 PM, Matthew Brush wrote:
On 2015-07-08 10:57 AM, Steven Blatnick wrote:
So I've finally got a chance to look at my non-API calls. I was able to
code around most of them, but there are two that would be much easier if
we could make them
On 2015-07-08 10:57 AM, Steven Blatnick wrote:
[snip]
Let me know if this is possible or how I should proceed. I use geany
with my plugins daily, and can't upgrade my code base until my plugins
are working.
I forgot to mention, if you made your plugin part of the Geany-Plugins
project (I'm a
On 2015-07-08 07:28 PM, Steve wrote:
On Jul 8, 2015 7:18 PM, Matthew Brush wrote:
On 2015-07-08 10:57 AM, Steven Blatnick wrote:
So I've finally got a chance to look at my non-API calls. I was able to
code around most of them, but there are two that would be much easier if
we could make the
On Jul 8, 2015 7:18 PM, Matthew Brush wrote:
>
> On 2015-07-08 10:57 AM, Steven Blatnick wrote:
> > So I've finally got a chance to look at my non-API calls. I was able to
> > code around most of them, but there are two that would be much easier if
> > we could make them APIs. (I haven't pus
On 2015-07-08 10:57 AM, Steven Blatnick wrote:
So I've finally got a chance to look at my non-API calls. I was able to
code around most of them, but there are two that would be much easier if
we could make them APIs. (I haven't pushed any of these changes to my
git repo yet.) Could we consider
On 2015-07-08 01:03 PM, Jiří Techet wrote:
On Wed, Jul 8, 2015 at 5:47 AM, Matthew Brush
Yeah, of course. I didn't mean, despite how the subject might sound,
that we could/should _never_ re-write a PR, just that we shouldn't do so
casually/by default, and that if rebasing is desired, that it
On Wed, Jul 8, 2015 at 5:47 AM, Matthew Brush wrote:
>
>
> I propose that we disallow force pushing, rebasing, squashing, etc.
>>> on any PR until it is fully ready for final merging. […] ready for
>>> merging. At that point it _might_ make sense to fudge history and get
>>> rid of some noisy "fi
So I've finally got a chance to look at my non-API calls. I was able to
code around most of them, but there are two that would be much easier if
we could make them APIs. (I haven't pushed any of these changes to my
git repo yet.) Could we consider making these API?
* keybindings_load_keyfi
Le 29/06/2015 10:24, Thomas Martitz a écrit :
> […]
>
> That helps only existing users, and only that fraction that actually
> reads release notes (I would think the bulk of them doesn't).
>
> Perhaps it would be indeed best to not toggle the default for this
> release already?
Makes sense to me
Le 08/07/2015 05:19, Matthew Brush a écrit :
> […]
>
> So does that mean it's ok to make comments either on the main page of
> the pull request or the "files changed" view which shows the combined
> changes?
Depends what you mean "ok", but yeah they shouldn't get lost.
The problem is that someti
11 matches
Mail list logo
