The following patches fix some problems in geany. More details can be found in the description of the individual patches:
[PATCH 1/3] Fix tab history switching [PATCH 2/3] Prevent -Wmissing-prototypes report warning when compiling a plugin [PATCH 3/3] Add .gitignore
Regards,
Jiri
There is a 600ms interval in which the panel displaying the current file name isn't displayed. If you switch tabs with a keybinding and do it too quickly (press it twice in the 600ms period), the wrong file is put on top of the stack. This patch fixes the problem
Signed-off-by: Jiří Techet techet@gmail.com --- src/keybindings.c | 65 +++++++++++++++++++++++++++++++--------------------- 1 files changed, 39 insertions(+), 26 deletions(-)
diff --git a/src/keybindings.c b/src/keybindings.c index 8347cc1..c297589 100644 --- a/src/keybindings.c +++ b/src/keybindings.c @@ -71,7 +71,7 @@ const gsize MAX_MRU_DOCS = 20; static GQueue *mru_docs = NULL; static guint mru_pos = 0;
-static gboolean switch_dialog_cancelled = TRUE; +static gboolean switch_in_progress = FALSE; static GtkWidget *switch_dialog = NULL; static GtkWidget *switch_dialog_label = NULL;
@@ -576,7 +576,7 @@ static void on_notebook_switch_page(void)
/* when closing current doc, old is NULL. * Don't add to the mru list when switch dialog is visible. */ - if (old && switch_dialog_cancelled) + if (old && !switch_in_progress) { g_queue_remove(mru_docs, old); g_queue_push_head(mru_docs, old); @@ -879,7 +879,7 @@ static GtkWidget *create_dialog(void) gtk_tree_view_append_column(GTK_TREE_VIEW(tree), column);
text_renderer = gtk_cell_renderer_text_new(); - column = gtk_tree_view_column_new_with_attributes(NULL, text_renderer, "text", 1, NULL); + column = gtk_tree_view_column_new_with_attributes(NULL, text_renderer, "text", 1, NULL); gtk_tree_view_append_column(GTK_TREE_VIEW(tree), column);
fill_shortcut_labels_treeview(tree); @@ -1751,12 +1751,15 @@ static void cb_func_switch_tabright(G_GNUC_UNUSED guint key_id) static gboolean on_key_release_event(GtkWidget *widget, GdkEventKey *ev, gpointer user_data) { /* user may have rebound keybinding to a different modifier than Ctrl, so check all */ - if (!switch_dialog_cancelled && is_modifier_key(ev->keyval)) + if (switch_in_progress && is_modifier_key(ev->keyval)) { - switch_dialog_cancelled = TRUE; + switch_in_progress = FALSE;
- if (switch_dialog && GTK_WIDGET_VISIBLE(switch_dialog)) - gtk_widget_hide(switch_dialog); + if (switch_dialog) + { + gtk_widget_destroy(switch_dialog); + switch_dialog = NULL; + }
mru_pos = 0; } @@ -1809,23 +1812,27 @@ static GtkWidget *create_switch_dialog(void) }
-static gboolean on_switch_timeout(G_GNUC_UNUSED gpointer data) +static void update_filename_label() { - if (switch_dialog_cancelled) + if (!switch_dialog) { - return FALSE; - } - if (! switch_dialog || !GTK_WIDGET_VISIBLE(switch_dialog)) - mru_pos = 2; /* skip past the previous document */ - else - mru_pos += 1; - - if (! switch_dialog) switch_dialog = create_switch_dialog(); + gtk_widget_show_all(switch_dialog); + }
geany_wrap_label_set_text(GTK_LABEL(switch_dialog_label), DOC_FILENAME(document_get_current())); - gtk_widget_show_all(switch_dialog); +} + + +static gboolean on_switch_timeout(G_GNUC_UNUSED gpointer data) +{ + if (!switch_in_progress || switch_dialog) + { + return FALSE; + } + + update_filename_label(); return FALSE; }
@@ -1848,19 +1855,25 @@ static void cb_func_switch_tablastused(G_GNUC_UNUSED guint key_id)
/* if there's a modifier key, we can switch back in MRU order each time unless * the key is released */ - if (! switch_dialog_cancelled) + if (!switch_in_progress) { - on_switch_timeout(NULL); /* update filename label */ - } - else - if (keybindings_lookup_item(GEANY_KEY_GROUP_NOTEBOOK, - GEANY_KEYS_NOTEBOOK_SWITCHTABLASTUSED)->mods) - { - switch_dialog_cancelled = FALSE; + switch_in_progress = TRUE; + + /* because switch_in_progress was not set when we called + * gtk_notebook_set_current_page() above, this function inserted last_doc + * into the queue => on mru_pos = 0 there is last_doc, on mru_pos = 1 + * there is the currently displayed doc, so we want to continue from 2 + * next time this function is called */ + mru_pos = 2;
/* delay showing dialog to give user time to let go of any modifier keys */ g_timeout_add(600, on_switch_timeout, NULL); } + else + { + update_filename_label(); /* update filename label */ + mru_pos += 1; + } }
On Wed, 9 Jun 2010 21:40:57 +0200 Jiří Techet techet@gmail.com wrote:
There is a 600ms interval in which the panel displaying the current file name isn't displayed. If you switch tabs with a keybinding and do it too quickly (press it twice in the 600ms period), the wrong file is put on top of the stack. This patch fixes the problem
Thanks, applied to: https://geany.svn.sourceforge.net/svnroot/geany/branches/unstable
Will merge to trunk after the release.
BTW, please could you attach any future patches rather than paste them in the message body so it's easier to save the patch as a file - sorry to moan ;-)
Regards, Nick
On Thu, Jun 10, 2010 at 13:40, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 9 Jun 2010 21:40:57 +0200 Jiří Techet techet@gmail.com wrote:
There is a 600ms interval in which the panel displaying the current file name isn't displayed. If you switch tabs with a keybinding and do it too quickly (press it twice in the 600ms period), the wrong file is put on top of the stack. This patch fixes the problem
Thanks, applied to: https://geany.svn.sourceforge.net/svnroot/geany/branches/unstable
Will merge to trunk after the release.
BTW, please could you attach any future patches rather than paste them in the message body so it's easier to save the patch as a file - sorry to moan ;-)
Sorry. I used git send-email for that but I think there is an --attach option that should do the trick. If it's too big problem I can re-post the patches again (after returning from work ;-)
Jiri
Signed-off-by: Jiří Techet techet@gmail.com --- src/plugindata.h | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/plugindata.h b/src/plugindata.h index aff3143..9facecb 100644 --- a/src/plugindata.h +++ b/src/plugindata.h @@ -64,6 +64,7 @@ enum { * - Geany ABI data types are compatible with this plugin. * - Geany sources provide the required API for this plugin. */ #define PLUGIN_VERSION_CHECK(api_required) \ + gint plugin_version_check(gint abi_ver);\ gint plugin_version_check(gint abi_ver) \ { \ if (abi_ver != GEANY_ABI_VERSION) \ @@ -111,6 +112,7 @@ GeanyPlugin; * extra PluginInfo features (such as an icon), so we don't need to break API * compatibility. Alternatively just add a new macro, PLUGIN_SET_INFO_FULL(). -ntrel */ #define PLUGIN_SET_INFO(p_name, p_description, p_version, p_author) \ + void plugin_set_info(PluginInfo* info);\ void plugin_set_info(PluginInfo* info) \ { \ info->name = (p_name); \
On Wed, 9 Jun 2010 21:40:58 +0200 Jiří Techet techet@gmail.com wrote:
Signed-off-by: Jiří Techet techet@gmail.com
src/plugindata.h | 2 ++
- gint plugin_version_check(gint abi_ver);\ gint plugin_version_check(gint abi_ver) \ { \
Why is this necessary?
Regards, Nick
On Thu, Jun 10, 2010 at 13:05, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 9 Jun 2010 21:40:58 +0200 Jiří Techet techet@gmail.com wrote:
Signed-off-by: Jiří Techet techet@gmail.com
src/plugindata.h | 2 ++
- gint plugin_version_check(gint abi_ver);\
gint plugin_version_check(gint abi_ver) \ { \
Why is this necessary?
If you don't compile the plugins with -Wmissing-prototypes then you don't get any warnings if you use a function that hasn't been declared (imagine you make a typo in a call of an API function or any of your internal functions). The plugin compiles just fine, but then it doesn't get loaded by geany on runtime and you have to start searching for what symbol is missing (using LD_DEBUG).
-Wmissing-prototypes requires that for every non-static function there is a previous declaration before it is defined/used. This is normally satisfied because these are in the header files - this macro is just an exceptional case.
In general, I would recommend that geany uses a slightly more strict set of warning options. I find the options used by gnome-common as a reasonable set:
-Wall -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-sign-compare
You might consider using them for the whole geany.
Regards,
Jiri
On Thu, 10 Jun 2010 13:33:44 +0200 Jiří Techet techet@gmail.com wrote:
On Thu, Jun 10, 2010 at 13:05, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 9 Jun 2010 21:40:58 +0200 Jiří Techet techet@gmail.com wrote:
Signed-off-by: Jiří Techet techet@gmail.com
src/plugindata.h | 2 ++
- gint plugin_version_check(gint abi_ver);\
gint plugin_version_check(gint abi_ver) \ { \
Why is this necessary?
If you don't compile the plugins with -Wmissing-prototypes then you don't get any warnings if you use a function that hasn't been declared (imagine you make a typo in a call of an API function or any of your internal functions). The plugin compiles just fine, but then it doesn't get loaded by geany on runtime and you have to start searching for what symbol is missing (using LD_DEBUG).
Wouldn't you get a warning with -Wall:
int main(int argc, char **argv) { foo(); return 0; }
$ gcc -c untitled.c -Wall untitled.c: In function ‘main’: untitled.c:28: warning: implicit declaration of function ‘foo’
-Wmissing-prototypes requires that for every non-static function there is a previous declaration before it is defined/used. This is normally satisfied because these are in the header files - this macro is just an exceptional case.
In general, I would recommend that geany uses a slightly more strict set of warning options. I find the options used by gnome-common as a reasonable set:
-Wall -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-sign-compare
You might consider using them for the whole geany.
This is (probably) less strict than our recommended warnings, see the HACKING file (-W and -ansi):
http://geany.org/manual/dev/hacking.html#coding
(Personally I also use -Werror with -Wno-unused-parameter for Geany)
Regards, Nick
On Thu, Jun 10, 2010 at 13:49, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 10 Jun 2010 13:33:44 +0200 Jiří Techet techet@gmail.com wrote:
On Thu, Jun 10, 2010 at 13:05, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 9 Jun 2010 21:40:58 +0200 Jiří Techet techet@gmail.com wrote:
Signed-off-by: Jiří Techet techet@gmail.com
src/plugindata.h | 2 ++
- gint plugin_version_check(gint abi_ver);\
gint plugin_version_check(gint abi_ver) \ { \
Why is this necessary?
If you don't compile the plugins with -Wmissing-prototypes then you don't get any warnings if you use a function that hasn't been declared (imagine you make a typo in a call of an API function or any of your internal functions). The plugin compiles just fine, but then it doesn't get loaded by geany on runtime and you have to start searching for what symbol is missing (using LD_DEBUG).
Wouldn't you get a warning with -Wall:
int main(int argc, char **argv) { foo(); return 0; }
$ gcc -c untitled.c -Wall untitled.c: In function ‘main’: untitled.c:28: warning: implicit declaration of function ‘foo’
Ah, sorry, you're right, this isn't the case - it's a different one. Imagine you have:
foo.h: void foo(void);
foo.c: #include "foo.h"
void foo(void) { printf("foo"); }
main.c: #include "foo.h"
int main(int argc, char **argv) { foo(); return 0; }
This is OK. Now you rename foo(void) in foo.c to foobar(void) but forget to update the header. It compiles just fine because main.c finds the declaration of foo(void) in foo.h, but its implementation is missing (so the compiler thinks it's an extern symbol, but it's not actually defined anywhere).
Just a note if you wish to use it - the declarations with no arguments have to be declared as
void foo(void);
and not
void foo();
-Wmissing-prototypes requires that for every non-static function there is a previous declaration before it is defined/used. This is normally satisfied because these are in the header files - this macro is just an exceptional case.
In general, I would recommend that geany uses a slightly more strict set of warning options. I find the options used by gnome-common as a reasonable set:
-Wall -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-sign-compare
You might consider using them for the whole geany.
This is (probably) less strict than our recommended warnings, see the HACKING file (-W and -ansi):
I would have to check what exactly -W and -ansi consist of but I think they don't contain -Wmissing-prototypes.
Jiri
<snip>
I would have to check what exactly -W and -ansi consist of but I think they don't contain -Wmissing-prototypes.
Thats right they don't. There was a big argument on another project site, -Wmissing-prototypes isn't automatic since the problem it detects is completely legal, but as you point out is probably an error since if the prototype of a global function isn't in a header how do users use it safely?
Cheers Lex
Jiri _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 10 Jun 2010 14:21:27 +0200 Jiří Techet techet@gmail.com wrote:
Imagine you have:
foo.h: void foo(void);
foo.c: #include "foo.h"
void foo(void) { printf("foo"); }
main.c: #include "foo.h"
int main(int argc, char **argv) { foo(); return 0; }
This is OK. Now you rename foo(void) in foo.c to foobar(void) but forget to update the header. It compiles just fine because main.c finds the declaration of foo(void) in foo.h, but its implementation is missing (so the compiler thinks it's an extern symbol, but it's not actually defined anywhere).
OK, thanks for explaining. It sounds like a good warning flag.
Your patch only provides prototypes for the 2 macro-defined functions, but we would need prototypes for all plugin functions geany calls to satisfy the flag.
One way we might do that is to turn doc/pluginsymbols.c into a header file and include that in geanyplugin.h. What do you think?
Regards, Nick
On 10 June 2010 23:51, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 10 Jun 2010 14:21:27 +0200 Jiří Techet techet@gmail.com wrote:
Imagine you have:
foo.h: void foo(void);
foo.c: #include "foo.h"
void foo(void) { printf("foo"); }
main.c: #include "foo.h"
int main(int argc, char **argv) { foo(); return 0; }
This is OK. Now you rename foo(void) in foo.c to foobar(void) but forget to update the header. It compiles just fine because main.c finds the declaration of foo(void) in foo.h, but its implementation is missing (so the compiler thinks it's an extern symbol, but it's not actually defined anywhere).
OK, thanks for explaining. It sounds like a good warning flag.
Your patch only provides prototypes for the 2 macro-defined functions, but we would need prototypes for all plugin functions geany calls to satisfy the flag.
One way we might do that is to turn doc/pluginsymbols.c into a header file and include that in geanyplugin.h. What do you think?
Yes, that would let the compiler check both sides of the plugin interface.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 10 Jun 2010 14:51:23 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
Your patch only provides prototypes for the 2 macro-defined functions, but we would need prototypes for all plugin functions geany calls to satisfy the flag.
One way we might do that is to turn doc/pluginsymbols.c into a header file and include that in geanyplugin.h. What do you think?
Yes, sounds reasonable if its works.
Cheers, Frank
On Thu, 10 Jun 2010 13:33:44 +0200, Jiří wrote:
On Thu, Jun 10, 2010 at 13:05, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 9 Jun 2010 21:40:58 +0200 Jiří Techet techet@gmail.com wrote:
Signed-off-by: Jiří Techet techet@gmail.com
src/plugindata.h | 2 ++
- gint plugin_version_check(gint abi_ver);\
gint plugin_version_check(gint abi_ver) \ { \
Why is this necessary?
If you don't compile the plugins with -Wmissing-prototypes then you don't get any warnings if you use a function that hasn't been declared (imagine you make a typo in a call of an API function or any of your internal functions). The plugin compiles just fine, but then it doesn't get loaded by geany on runtime and you have to start searching for what symbol is missing (using LD_DEBUG).
-Wmissing-prototypes requires that for every non-static function there is a previous declaration before it is defined/used. This is normally satisfied because these are in the header files - this macro is just an exceptional case.
In general, I would recommend that geany uses a slightly more strict set of warning options. I find the options used by gnome-common as a reasonable set:
-Wall -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-sign-compare
You might consider using them for the whole geany.
Just as an additional note: compiler flags should always be used by individual developers/users, not by the used build system directly. -Wmissing-prototypes and friends are gcc specific and would break building with other compilers.
I guess you didn't mean to add them to the build system directly :).
Regards, Enrico
2010/6/12 Enrico Tröger enrico.troeger@uvena.de:
On Thu, 10 Jun 2010 13:33:44 +0200, Jiří wrote:
On Thu, Jun 10, 2010 at 13:05, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 9 Jun 2010 21:40:58 +0200 Jiří Techet techet@gmail.com wrote:
Signed-off-by: Jiří Techet techet@gmail.com
src/plugindata.h | 2 ++
- gint plugin_version_check(gint abi_ver);\
gint plugin_version_check(gint abi_ver) \ { \
Why is this necessary?
If you don't compile the plugins with -Wmissing-prototypes then you don't get any warnings if you use a function that hasn't been declared (imagine you make a typo in a call of an API function or any of your internal functions). The plugin compiles just fine, but then it doesn't get loaded by geany on runtime and you have to start searching for what symbol is missing (using LD_DEBUG).
-Wmissing-prototypes requires that for every non-static function there is a previous declaration before it is defined/used. This is normally satisfied because these are in the header files - this macro is just an exceptional case.
In general, I would recommend that geany uses a slightly more strict set of warning options. I find the options used by gnome-common as a reasonable set:
-Wall -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-sign-compare
You might consider using them for the whole geany.
Just as an additional note: compiler flags should always be used by individual developers/users, not by the used build system directly.
Why? If you want to ensure that the sources satisfy some standards, then it's alright. You use -Wall after all.
-Wmissing-prototypes and friends are gcc specific and would break building with other compilers.
I guess you didn't mean to add them to the build system directly :).
You can use gnome-compiler-flags.m4 from the gnome-common package that checks whether you use gcc for compilation and only in this case the above flags are added (it adds a configure parameter where the set of flags can be configured).
Regards,
Jiri
On 13 June 2010 03:46, Jiří Techet techet@gmail.com wrote:
2010/6/12 Enrico Tröger enrico.troeger@uvena.de:
On Thu, 10 Jun 2010 13:33:44 +0200, Jiří wrote:
On Thu, Jun 10, 2010 at 13:05, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 9 Jun 2010 21:40:58 +0200 Jiří Techet techet@gmail.com wrote:
Signed-off-by: Jiří Techet techet@gmail.com
src/plugindata.h | 2 ++
- gint plugin_version_check(gint abi_ver);\
gint plugin_version_check(gint abi_ver) \ { \
Why is this necessary?
If you don't compile the plugins with -Wmissing-prototypes then you don't get any warnings if you use a function that hasn't been declared (imagine you make a typo in a call of an API function or any of your internal functions). The plugin compiles just fine, but then it doesn't get loaded by geany on runtime and you have to start searching for what symbol is missing (using LD_DEBUG).
-Wmissing-prototypes requires that for every non-static function there is a previous declaration before it is defined/used. This is normally satisfied because these are in the header files - this macro is just an exceptional case.
In general, I would recommend that geany uses a slightly more strict set of warning options. I find the options used by gnome-common as a reasonable set:
-Wall -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-sign-compare
You might consider using them for the whole geany.
Just as an additional note: compiler flags should always be used by individual developers/users, not by the used build system directly.
Why? If you want to ensure that the sources satisfy some standards, then it's alright. You use -Wall after all.
-Wmissing-prototypes and friends are gcc specific and would break building with other compilers.
I guess you didn't mean to add them to the build system directly :).
You can use gnome-compiler-flags.m4 from the gnome-common package that checks whether you use gcc for compilation and only in this case the above flags are added (it adds a configure parameter where the set of flags can be configured).
Regards,
Jiri
I think its worth putting the prototypes in the header as Nick suggests even without this being a standard build flag. Then if the prototype even did have to change or, heaven forbid, the plugin writer makes a mistake, the compiler has a chance of warning you.
Then you only need -Wmissing-prototypes occasionally to check for "dangling functions".
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sat, 12 Jun 2010 19:46:00 +0200, Jiří wrote:
2010/6/12 Enrico Tröger enrico.troeger@uvena.de:
On Thu, 10 Jun 2010 13:33:44 +0200, Jiří wrote:
On Thu, Jun 10, 2010 at 13:05, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 9 Jun 2010 21:40:58 +0200 Jiří Techet techet@gmail.com wrote:
Signed-off-by: Jiří Techet techet@gmail.com
src/plugindata.h | 2 ++
- gint plugin_version_check(gint abi_ver);\
gint plugin_version_check(gint abi_ver) \ { \
Why is this necessary?
If you don't compile the plugins with -Wmissing-prototypes then you don't get any warnings if you use a function that hasn't been declared (imagine you make a typo in a call of an API function or any of your internal functions). The plugin compiles just fine, but then it doesn't get loaded by geany on runtime and you have to start searching for what symbol is missing (using LD_DEBUG).
-Wmissing-prototypes requires that for every non-static function there is a previous declaration before it is defined/used. This is normally satisfied because these are in the header files - this macro is just an exceptional case.
In general, I would recommend that geany uses a slightly more strict set of warning options. I find the options used by gnome-common as a reasonable set:
-Wall -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-sign-compare
You might consider using them for the whole geany.
Just as an additional note: compiler flags should always be used by individual developers/users, not by the used build system directly.
Why? If you want to ensure that the sources satisfy some standards, then it's alright. You use -Wall after all.
Really? I had a quick look and didn't find any reference. Did I miss anything?
-Wmissing-prototypes and friends are gcc specific and would break building with other compilers.
I guess you didn't mean to add them to the build system directly :).
You can use gnome-compiler-flags.m4 from the gnome-common package that checks whether you use gcc for compilation and only in this case the above flags are added (it adds a configure parameter where the set of flags can be configured).
Ok. But IMO this is overhead we don't need. Specific compiler flags (more specific than -c, -o and -g), should be in the responsibility of each individual developer. But of course, we could add the mentioned flag as hint in the HACKING file.
Regards, Enrico
Why? If you want to ensure that the sources satisfy some standards, then it's alright. You use -Wall after all.
Really? I had a quick look and didn't find any reference. Did I miss anything?
My imagination, apparently ;-).
-Wmissing-prototypes and friends are gcc specific and would break building with other compilers.
I guess you didn't mean to add them to the build system directly :).
You can use gnome-compiler-flags.m4 from the gnome-common package that checks whether you use gcc for compilation and only in this case the above flags are added (it adds a configure parameter where the set of flags can be configured).
Ok. But IMO this is overhead we don't need. Specific compiler flags (more specific than -c, -o and -g), should be in the responsibility of each individual developer. But of course, we could add the mentioned flag as hint in the HACKING file.
It's fine as long as there is someone who regularly checks that the compilation works without warnings even with stricter compiler flags. But from my experience, things like that are often forgotten...
Regarding the "overhead" (if there was some, I seriously doubt it will be something measurable), you should distinguish two types of users:
1. Developers - these will feel the overhead because they compile geany often. But these are also those that definitely _should_ use the flags.
2. Users - these will download geany when you make a release and compile it. For them it will be a useless overhead but because they download and compile geany twice a year, they won't care whether the compilation takes a few more seconds.
So I don't find any audience that would be affected by enabling the flags in a negative way. I'm not saying that you have to enable them - this is really up to you - I'm just saying what I would do.
Regards,
Jiri
Add .gitignore to eliminate the files we do not want to see in git
Signed-off-by: Jiří Techet techet@gmail.com --- .gitignore | 37 +++++++++++++++++++++++++++++++++++++ 1 files changed, 37 insertions(+), 0 deletions(-) create mode 100644 .gitignore
diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..984882e --- /dev/null +++ b/.gitignore @@ -0,0 +1,37 @@ +Makefile +Makefile.in +aclocal.m4 +config.guess +config.h +config.h.in +config.sub +configure +install-sh +ltmain.sh +missing +depcomp +mkinstalldirs +autom4te.cache +config.log +config.status +libtool +.deps +.libs +stamp-h1 +*.o +*.la +*.lai +*.so +*.lo +doc/Doxyfile +doc/geany.1 +geany.desktop +geany.pc +geany.spec +intltool-*.in +po/Makefile.in.in +po/POTFILES +po/stamp-it +*.gmo +*.a +src/geany
Hi,
On Wed, 9 Jun 2010 21:40:59 +0200 Jiří Techet techet@gmail.com wrote:
Add .gitignore to eliminate the files we do not want to see in git
I don't see any need to add an .gitignore to the subversion repository and suggest to have this only locally.
Cheers, Frank
On Thu, Jun 10, 2010 at 18:36, Frank Lanitz frank@frank.uvena.de wrote:
Hi,
On Wed, 9 Jun 2010 21:40:59 +0200 Jiří Techet techet@gmail.com wrote:
Add .gitignore to eliminate the files we do not want to see in git
I don't see any need to add an .gitignore to the subversion repository and suggest to have this only locally.
I just find it a bit unfriendly to people who clone geany from the git repository. I think .gitignore isn't that big that it presence should worry SVN users much. Just my opinion.
Jiri
On 06/10/2010 09:59 AM, Jiří Techet wrote:
On Thu, Jun 10, 2010 at 18:36, Frank Lanitzfrank@frank.uvena.de wrote:
Hi,
On Wed, 9 Jun 2010 21:40:59 +0200 Jiří Techettechet@gmail.com wrote:
Add .gitignore to eliminate the files we do not want to see in git
I don't see any need to add an .gitignore to the subversion repository and suggest to have this only locally.
I just find it a bit unfriendly to people who clone geany from the git repository. I think .gitignore isn't that big that it presence should worry SVN users much. Just my opinion.
Jiri
Would you also add (and maintain) a .hgignore file? I use Mercurial, after all...
Sorry for the rhetoric question. :) I agree with Frank; this is a good suggestion for git users, but doesn't really belong upstream. Maybe if git becomes the official source control system at some point in the future.
Am 10.06.2010 18:36, schrieb Frank Lanitz:
Hi,
On Wed, 9 Jun 2010 21:40:59 +0200 Jiří Techettechet@gmail.com wrote:
Add .gitignore to eliminate the files we do not want to see in git
I don't see any need to add an .gitignore to the subversion repository and suggest to have this only locally.
Except that there's an *official* git mirror which makes it reasonable to have it in the repo.
Best regards.
On Thu, 10 Jun 2010 21:44:09 +0200 Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 10.06.2010 18:36, schrieb Frank Lanitz:
Hi,
On Wed, 9 Jun 2010 21:40:59 +0200 Jiří Techettechet@gmail.com wrote:
Add .gitignore to eliminate the files we do not want to see in git
I don't see any need to add an .gitignore to the subversion repository and suggest to have this only locally.
Except that there's an *official* git mirror which makes it reasonable to have it in the repo.
At least IMHO the git repo is not a real official as its just a mirror.
Cheers, Frank