Re: [Geany-devel] Geany-Plugins: MAINTAINERS file
Hi I suggest dropping the Paid status altogether if no one has used it by the time all the plugins' info is filled in. I disagree. Currently there might be no plugin maintainer being paid to work on a plugin, but: - this might change (...) - is something user should be able to see to resynch there demandings with reality. I'm reading e.g. support@pidgin mailing list and more than once a week I need to facepalm myself because of users don't understand they are not talking to some paid support. I really don't want to end up on Geany with such situation. Even if someone is paid, he will probably be paid to do something that person that is paying want (feature, bug fix), not helping random people with support. But such status will just make someone say something like: Hey, you are being paid, DO AS I WANT AT ONCE!!! -- Best regards, Yury Siamashka ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [geanyprj] coding style patch
Hi Sorry I didn't follow conversion to github and I am not really familiar with new workflow. So as GeanyPrj maintainer how do I commit patch to mainline? Should my github user be added to main geany-plugins repository or I need to create new fork with related changes and create pull request to main geany-plugins from time to time? This github stuff is a bit confusing for me. On 12/12/2011 06:51 AM, Johann SAUNIER wrote: Hi there, This is a new patch for Geanyprj. It doesn't implement any functionality or bug fix. It's only a cosmetic patch to comply to Geany's coding conventions. Since geany-plugins has moved on GitHub, is there an equivalent to the tracker-patches functionality of SourceForge for sending patches ? Yep, In Github land it's called a pull request. While logged in to Github, navigate to the geany-plugins repository and click the fork button. It will make a copy of the repository under your account. Create a new branch, hack away and when it's ready, click the Pull request button on Github and it will notify committers that you have something ready in your branch to be merged. Of course like you did here on the ML is fine too, but it's easier to loose track of if it's not persistent somewhere. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel -- Yura Siamashka yura...@gmail.com ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] How about calling the next release 1.0?
On Thu, 22 Sep 2011 15:28:21 +0200 Colomban Wendling lists@herbesfolles.org wrote: What about Geany 3000? Or some kind of other stupid release name like ''busel', 'verabei', 'krumkach' ... Heh, I like krumkach, sounds in German quite funny :). BTW, how are Geany codenames chosen? :-' My list just uses belarussian birds names: stork(busel), sparrow(verabei), raven(krumkach) -- Yura Siamashka yura...@gmail.com ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] How about calling the next release 1.0?
Hi But why only 1.0? GNOME 3.* KDE 4.* Scite 2.* What about Geany 3000? Or some kind of other stupid release name like ''busel', 'verabei', 'krumkach' ... Best regards, Yura Siamashka On 20/09/2011, Thomas Martitz thomas.mart...@student.htw-berlin.de wrote: Am Di, 20.09.2011, 13:43 schrieb Lex Trotman: On 20 September 2011 21:23, Frank Lanitz fr...@frank.uvena.de wrote: Hi, Am 20.09.2011 12:07, schrieb Ji?í Techet: just one very quick and possibly stupid idea. How about getting rid of the 0 version prefix and calling the next release 1.0? To make it short: As we are about two weeks ahead of next release I disagree. After 0.21 release we got a lot of structural changes we might could think about a 1.0 too, but I don't feel its needed at the moment. I have to disagree with you on this Frank, the version number is nothing to do with structural or technical issues, it is a project issue. Changing the version number doesn't affect translation or anything else that takes time to do, so it isn't going to delay the release. I agree. There's no reason to wait until after the upcoming release. 1.0: the earlier, the better. This release should be the most stable one ever made, so 1.0 is even more justified. 0.X simply isn't justified anymore. It sounds like Geany was alpha software, but it has indeed better release quality that the majority of software out there. Best regards. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel -- Best regards, Yury Siamashka ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Performance issues? [PATCH]
Hi On Sun, 27 Mar 2011 14:15:45 +1100 Lex Trotman ele...@gmail.com wrote: 1) geanyprj act only on document-open, document-save, document-activate callbacks 2) geanyprj add a lot of TMWorkObject objects using tm_workspace_add_object() to Geany And tm_workspace_add_object sets the parent to be the whole workspace! Can something be done for this? Because of item 2) above I think this will reparse all open files. I don't think it is true. I used mantisbt project to test. Initially it takes few seconds to load the project (parse all files). Delay during typing is much less then second. Anyway here is patch that make Geany don't parse tags when user is actively typing. -- Yura Siamashka yura...@gmail.com update-tags-only-on-idle.patch Description: Binary data ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Performance issues?
On Wed, 23 Mar 2011 23:49:41 +1100 Lex Trotman ele...@gmail.com wrote: Thats a bit harder, probably Yura, the plugin writer will need to take a look at the problem I'd say. I looked at the problem: 1) geanyprj act only on document-open, document-save, document-activate callbacks 2) geanyprj add a lot of TMWorkObject objects using tm_workspace_add_object() to Geany 3) Geany call update_tags_from_buffer() very often. I think this function somehow reparse a lot of objects because of update_parent param. I am not sure what this param actualy mean but if I change function this way performance is back to normal (I don't say we need to change it, it is just research): --- a/src/document.c +++ b/src/document.c @@ -2263,7 +2263,7 @@ static gboolean update_tags_from_buffer(GeanyDocument *doc) /* we copy the whole text into memory instead using a direct char pointer from * Scintilla because tm_source_file_buffer_update() does modify the string slightly */ sci_get_text(doc-editor-sci, len, text); - result = tm_source_file_buffer_update(doc-tm_file, (guchar*) text, len, TRUE); + result = tm_source_file_buffer_update(doc-tm_file, (guchar*) text, len, FALSE); g_free(text); #endif return result; -- Yura Siamashka yura...@gmail.com ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Ideas on increasing quality of plugins
On Sat, 12 Mar 2011 02:53:47 +0100 Colomban Wendling lists@herbesfolles.org wrote: Unfortunately, believe me that non-fatal warnings are use to be ignored by unexperienced programmers, believing that if their code compile it is then OK. And I don't see why a warning upgraded to an error on every build would be worst than a syntactical problem (as I described above previously)? In a typical situation, the developer who writes the plugin should get the warning (well, the error), see his plugin don't build, care (hopefully :D), and then fix it directly even before committing and then before anybody else could face the problem. Don't you think? Sorry I have not read all thread but here is my 2 cents. Warnings as errors are bad because different compiler version can generate different compile warnings. So It can be pain for developer to find and fix all warning for all compiler versions in the world. This issue is the same for for all other validation tools (valgrind, etc). Actually such maintains bother can be enough reason to abandon geany-plugins and move plugins to somewhere else. -- Yura Siamashka yura...@gmail.com ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] POLL: Mark developers names on plugins translateable Yes/No
On Mon, 27 Dec 2010 01:30:38 +0100 Frank Lanitz fr...@frank.uvena.de wrote: Hi folks, During review of German translation of Geany-Plugins I found a number of author's names marked as translatable. I don't see any big reason for doing this as most likely (and from my current point of view in all cases) it's just a copy paste task when doing the translation. Therefor I suggest to don't mark author's names as a translatable at all. What do you think about? I vote to left them translatable, copy paste is simple enough, but if language uses different set of characters (for example cyrillic), English names can look weird. On other hand I don't know how to spell correctly most of the names so I leave them English. -- Yura Siamashka yura...@gmail.com ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Plugin Keybindings (default values)
Hi
I am writting python debugger plugin which will use a lot of keys. So question:
How can I assign default shortcuts to actions like toggle breakpoint,
next command etc
so user will not have to assign a lot of keys himself.
Also please add sci_set_marker_at_line and sci_is_marker_set_at_line
to plugin API. I will need them to show breakpoints and current line
when debugging.
patch is attached
--
Best regards,
Yury Siamashka
diff --git a/plugins/geanyfunctions.h b/plugins/geanyfunctions.h
index 234961c..288690f 100644
--- a/plugins/geanyfunctions.h
+++ b/plugins/geanyfunctions.h
@@ -168,6 +168,10 @@
geany_functions-p_sci-set_target_end
#define sci_replace_target \
geany_functions-p_sci-replace_target
+#define sci_set_marker_at_line \
+ geany_functions-p_sci-set_marker_at_line
+#define sci_is_marker_set_at_line \
+ geany_functions-p_sci-is_marker_set_at_line
#define templates_get_template_fileheader \
geany_functions-p_templates-get_template_fileheader
#define utils_str_equal \
diff --git a/src/plugindata.h b/src/plugindata.h
index 42fae7b..d2c0ed2 100644
--- a/src/plugindata.h
+++ b/src/plugindata.h
@@ -50,7 +50,7 @@
enum {
/** The Application Programming Interface (API) version, incremented
* whenever any plugin data types are modified or appended to. */
- GEANY_API_VERSION = 155,
+ GEANY_API_VERSION = 156,
/** The Application Binary Interface (ABI) version, incremented whenever
* existing fields in the plugin data types have to be changed or reordered. */
@@ -341,6 +341,8 @@ typedef struct SciFuncs
void (*set_target_start) (ScintillaObject *sci, gint start);
void (*set_target_end) (ScintillaObject *sci, gint end);
gint (*replace_target) (ScintillaObject *sci, const gchar *text, gboolean regex);
+ void (*set_marker_at_line) (ScintillaObject* sci, gint line_number, gboolean set, gint marker );
+ gboolean (*is_marker_set_at_line) (ScintillaObject* sci, gint line, gint marker);
}
SciFuncs;
diff --git a/src/plugins.c b/src/plugins.c
index 395b3fe..645b0ea 100644
--- a/src/plugins.c
+++ b/src/plugins.c
@@ -171,7 +171,9 @@ static SciFuncs sci_funcs = {
sci_get_line_end_position,
sci_set_target_start,
sci_set_target_end,
- sci_replace_target
+ sci_replace_target,
+ sci_set_marker_at_line,
+ sci_is_marker_set_at_line
};
static TemplateFuncs template_funcs = {
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Nightly build failed: Plugins Windows build
Hi On Wed, 9 Sep 2009 03:51:55 + (UTC) nore...@nightly.geany.org wrote: See http://nightly.geany.org/win32/build_win32_plugins_stderr.log for details. Error messages: ../../plugins_svn/codenav/src/codenavigation.c: In function `switch_menu_item_activate': ../../plugins_svn/codenav/src/codenavigation.c:251: warning: comparison between signed and unsigned ../../plugins_svn/codenav/src/codenavigation.c:315: warning: ISO C90 forbids mixed declarations and code ../../plugins_svn/geanylua/glspi_run.c: In function `debug_hook': ... ../../plugins_svn/geanyprj/src/sidebar.c:278: warning: ISO C90 forbids mixed declarations and code default/geanyprj/src/utils_11.o: In function `save_config': /home/enrico/geany/_build_/plugins_win32/../../plugins_svn/geanyprj/src/utils.c:170: undefined reference to `_utils_write_file' collect2: ld returned 1 exit status Can anyone help me with this error? I have no idea how to fix this error. -- Yura Siamashka yura...@gmail.com ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] ANN: New Release: Geany 0.18
On Tue, 18 Aug 2009 00:05:59 +0200 Enrico Tröger enrico.troe...@uvena.de wrote: They indeed broke. I think this should be fixed now in SVN by mapping the numpad keys to their normal equivalents, the code is based on the same thing happening in Scintilla. If it doesn't work or breaks something else or not all necessary keys were mapped, just tell us, as usual :). Thanks, everything works fine now. That was really fast. -- Yura Siamashka yura...@gmail.com ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] ANN: New Release: Geany 0.18
On Sun, 16 Aug 2009 20:45:00 +0200 Enrico Tröger enrico.troe...@uvena.de wrote: we are happy to announce a new release of Geany! It seems that KP_End and KP_Home keys don't work in 0.18. End and Home key works fine. In 0.17 End, Home, KP_End and KP_Home works fine. Tested at work and at home (x86 and amd64). -- Yura Siamashka yura...@gmail.com ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
