The following patches are required by gproject to build and run correctly. More details in the individual patches.
[PATCH 1/3] Add a signal that is emitted before build starts [PATCH 2/3] Make it possible to fill some fields of find in files dialog by plugins [PATCH 3/3] Open files from msgwindow even if find_in_files_dir is not set
Jiri
Signed-off-by: Jiří Techet techet@gmail.com --- doc/plugins.dox | 12 ++++++++++++ src/build.c | 2 ++ src/geanyobject.c | 8 ++++++++ src/geanyobject.h | 2 ++ 4 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/doc/plugins.dox b/doc/plugins.dox index df156eb..ba3128a 100644 --- a/doc/plugins.dox +++ b/doc/plugins.dox @@ -253,6 +253,18 @@ PluginCallback plugin_callbacks[] = * @param user_data user data. * @endsignaldef * + * @signaldef build-notify + * @signalproto + * void user_function(GObject *obj, gpointer user_data); + * @endsignalproto + * @signaldesc + * Sent before build is started. Plugins can use this signal e.g. to save the opened documents + * before the build starts. + * + * @param obj a GeanyObject instance, should be ignored. + * @param user_data user data. + * @endsignaldef + * * @signaldef update-editor-menu * @signalproto * void user_function(GObject *obj, const gchar *word, gint pos, GeanyDocument *doc, diff --git a/src/build.c b/src/build.c index 2baa035..66cb52c 100644 --- a/src/build.c +++ b/src/build.c @@ -1243,6 +1243,8 @@ static void on_build_menu_item(GtkWidget *w, gpointer user_data) gint grp = GPOINTER_TO_GRP(user_data); gint cmd = GPOINTER_TO_CMD(user_data);
+ g_signal_emit_by_name(geany_object, "build-notify"); + if (doc && doc->changed) document_save_file(doc, FALSE); if (grp == GEANY_GBG_NON_FT && cmd == GBO_TO_CMD(GEANY_GBO_CUSTOM)) diff --git a/src/geanyobject.c b/src/geanyobject.c index 6e4d36e..41e6e16 100644 --- a/src/geanyobject.c +++ b/src/geanyobject.c @@ -292,6 +292,14 @@ static void create_signals(GObjectClass *g_object_class) NULL, NULL, g_cclosure_marshal_VOID__VOID, G_TYPE_NONE, 0); + geany_object_signals[GCB_BUILD_NOTIFY] = g_signal_new ( + "build-notify", + G_OBJECT_CLASS_TYPE (g_object_class), + G_SIGNAL_RUN_FIRST, + G_STRUCT_OFFSET (GeanyObjectClass, build_notify), + NULL, NULL, + g_cclosure_marshal_VOID__VOID, + G_TYPE_NONE, 0);
/* Core-only signals */ geany_object_signals[GCB_SAVE_SETTINGS] = g_signal_new ( diff --git a/src/geanyobject.h b/src/geanyobject.h index 1bfc70f..aa04613 100644 --- a/src/geanyobject.h +++ b/src/geanyobject.h @@ -45,6 +45,7 @@ typedef enum GCB_UPDATE_EDITOR_MENU, GCB_EDITOR_NOTIFY, GCB_GEANY_STARTUP_COMPLETE, + GCB_BUILD_NOTIFY, GCB_SAVE_SETTINGS, GCB_LOAD_SETTINGS, GCB_MAX @@ -90,6 +91,7 @@ struct _GeanyObjectClass void (*update_editor_menu)(const gchar *word, gint click_pos, GeanyDocument *doc); gboolean (*editor_notify)(GeanyEditor *editor, gpointer scnt); void (*geany_startup_complete)(void); + void (*build_notify)(void); void (*save_settings)(GKeyFile *keyfile); void (*load_settings)(GKeyFile *keyfile); };
On Wed, 9 Jun 2010 21:49:04 +0200 Jiří Techet techet@gmail.com wrote:
--- a/src/build.c +++ b/src/build.c @@ -1243,6 +1243,8 @@ static void on_build_menu_item(GtkWidget *w, gpointer user_data) gint grp = GPOINTER_TO_GRP(user_data); gint cmd = GPOINTER_TO_CMD(user_data);
- g_signal_emit_by_name(geany_object, "build-notify");
- if (doc && doc->changed) document_save_file(doc, FALSE); if (grp == GEANY_GBG_NON_FT && cmd == GBO_TO_CMD(GEANY_GBO_CUSTOM))
Applied now in SVN but changed name to "build-start".
Regards, Nick
This patch makes it possible for plugins to fill the values of the "search for" and "extra options" fields of the find in files dialog.
Signed-off-by: Jiří Techet techet@gmail.com --- plugins/geanyfunctions.h | 2 ++ src/plugindata.h | 1 + src/plugins.c | 3 ++- src/search.c | 21 +++++++++++++++++++-- src/search.h | 1 + 5 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/plugins/geanyfunctions.h b/plugins/geanyfunctions.h index 0b0556e..d015ffd 100644 --- a/plugins/geanyfunctions.h +++ b/plugins/geanyfunctions.h @@ -316,6 +316,8 @@ geany_functions->p_tm->tm_workspace_remove_object #define search_show_find_in_files_dialog \ geany_functions->p_search->search_show_find_in_files_dialog +#define search_show_find_in_files_dialog_with_extra_opt \ + geany_functions->p_search->search_show_find_in_files_dialog_with_extra_opt #define highlighting_get_style \ geany_functions->p_highlighting->highlighting_get_style #define highlighting_set_styles \ diff --git a/src/plugindata.h b/src/plugindata.h index 5405639..aff3143 100644 --- a/src/plugindata.h +++ b/src/plugindata.h @@ -544,6 +544,7 @@ FiletypeFuncs; typedef struct SearchFuncs { void (*search_show_find_in_files_dialog) (const gchar *dir); + void (*search_show_find_in_files_dialog_with_extra_opt) (const gchar *dir, const gchar *extra_opt); } SearchFuncs;
diff --git a/src/plugins.c b/src/plugins.c index 8269111..db421b0 100644 --- a/src/plugins.c +++ b/src/plugins.c @@ -281,7 +281,8 @@ static TagManagerFuncs tagmanager_funcs = { };
static SearchFuncs search_funcs = { - &search_show_find_in_files_dialog + &search_show_find_in_files_dialog, + &search_show_find_in_files_dialog_with_extra_opt };
static HighlightingFuncs highlighting_funcs = { diff --git a/src/search.c b/src/search.c index 3e60f62..2149629 100644 --- a/src/search.c +++ b/src/search.c @@ -126,9 +126,10 @@ static struct GtkWidget *dir_combo; GtkWidget *search_combo; GtkWidget *encoding_combo; + GtkWidget *extra_opt_entry; gint position[2]; /* x, y */ } -fif_dlg = {NULL, NULL, NULL, NULL, {0, 0}}; +fif_dlg = {NULL, NULL, NULL, NULL, NULL, {0, 0}};
static gboolean search_read_io(GIOChannel *source, GIOCondition condition, gpointer data); @@ -850,6 +851,7 @@ static void create_fif_dialog(void) gtk_widget_set_sensitive(entry_extra, FALSE); ui_widget_set_tooltip_text(entry_extra, _("Other options to pass to Grep")); ui_hookup_widget(fif_dlg.dialog, entry_extra, "entry_extra"); + fif_dlg.extra_opt_entry = entry_extra;
/* enable entry_extra when check_extra is checked */ g_signal_connect(check_extra, "toggled", @@ -871,7 +873,7 @@ static void create_fif_dialog(void)
/* dir is the directory to search in (UTF-8 encoding), maybe NULL to determine it the usual way * by using the current file's path */ -void search_show_find_in_files_dialog(const gchar *dir) +static void search_show_find_in_files_dialog_internal(const gchar *dir, const gchar *extra_opt) { GtkWidget *entry; /* for child GtkEntry of a GtkComboBoxEntry */ GeanyDocument *doc = document_get_current(); @@ -930,6 +932,9 @@ void search_show_find_in_files_dialog(const gchar *dir) g_free(cur_dir); }
+ if (NZV(extra_opt)) + gtk_entry_set_text(GTK_ENTRY(fif_dlg.extra_opt_entry), extra_opt); + /* set the encoding of the current file */ if (doc != NULL) enc_idx = encodings_get_idx_from_charset(doc->encoding); @@ -950,6 +955,18 @@ void search_show_find_in_files_dialog(const gchar *dir) }
+void search_show_find_in_files_dialog(const gchar *dir) +{ + search_show_find_in_files_dialog_internal(dir, NULL); +} + + +void search_show_find_in_files_dialog_with_extra_opt(const gchar *dir, const gchar *extra_opt) +{ + search_show_find_in_files_dialog_internal(dir, extra_opt); +} + + static void on_find_replace_checkbutton_toggled(GtkToggleButton *togglebutton, gpointer user_data) { diff --git a/src/search.h b/src/search.h index 0934990..26389f6 100644 --- a/src/search.h +++ b/src/search.h @@ -67,6 +67,7 @@ void search_show_replace_dialog(void);
void search_show_find_in_files_dialog(const gchar *dir);
+void search_show_find_in_files_dialog_with_extra_opt(const gchar *dir, const gchar *extra_opt);
struct _ScintillaObject; struct Sci_TextToFind;
It should be possible to open files from the msgwindow even if find_in_files_dir is not set (when providing full path)
Signed-off-by: Jiří Techet techet@gmail.com --- src/msgwindow.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/msgwindow.c b/src/msgwindow.c index 302c82a..3b460ce 100644 --- a/src/msgwindow.c +++ b/src/msgwindow.c @@ -1042,7 +1042,7 @@ static void msgwin_parse_grep_line(const gchar *string, gchar **filename, gint * *filename = NULL; *line = -1;
- if (string == NULL || msgwindow.find_in_files_dir == NULL) + if (string == NULL) return;
/* conflict:3:conflicting types for `foo' */ @@ -1053,7 +1053,9 @@ static void msgwin_parse_grep_line(const gchar *string, gchar **filename, gint * data.file_idx = 0;
parse_file_line(&data, filename, line); - make_absolute(filename, msgwindow.find_in_files_dir); + + if (msgwindow.find_in_files_dir != NULL) + make_absolute(filename, msgwindow.find_in_files_dir); }
On Wed, 9 Jun 2010 21:49:03 +0200 Jiří Techet techet@gmail.com wrote:
The following patches are required by gproject to build and run correctly. More details in the individual patches.
[PATCH 1/3] Add a signal that is emitted before build starts [PATCH 2/3] Make it possible to fill some fields of find in files dialog by plugins [PATCH 3/3] Open files from msgwindow even if find_in_files_dir is not set
Can you explain more about how you want to use these changes?
Regards, Nick
Hi Nick,
sure, the explanation follows next:
On Thu, Jun 17, 2010 at 16:28, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 9 Jun 2010 21:49:03 +0200 Jiří Techet techet@gmail.com wrote:
The following patches are required by gproject to build and run correctly. More details in the individual patches.
[PATCH 1/3] Add a signal that is emitted before build starts
I want to be able to save all project files before the build starts. Currently geany saves only the active file but does nothing with the other open files, so you may be compiling the old version. I think emitting the signal before build might be useful for other plugins too (e.g. if they pre-process the files before the build and so on)
[PATCH 2/3] Make it possible to fill some fields of find in files dialog by plugins
There are two fields that I find it useful to pre-set in the find in files dialog:
* the path - my plugin displays a project file tree in the sidebar and right-clicking a folder and selecting "find in directory" pre-fills the directory in the dialog for the user. This saves a lot of time especially when the directory structure is deep.
* extra options - in my plugin the project files are defined by a set of patterns, so by providing a base path and patterns like *.c;*.h;*.am he defines the files he'll see in the sidebar and that are "inside" the project. Search in project files applies only to these files (and for big projects you really don't want to search *.o and others) so you need to restrict grep by something like
--include=*.c --include=*.h --include=*.am
Unfortunately the more file types you have, the more typing it involves so the plugin does this for you.
I can imagine that other plugins might find it useful to change the "search for" field and that the "extra options" checkbox might be also plugin-settable so I could add those too if you wish.
[PATCH 3/3] Open files from msgwindow even if find_in_files_dir is not set
Currently if you want to open a file by double clicking the filename in the msgwindow (e.g. after searching in files), the file is opened only after the project had been opened for the first time (subsequent closing the project doesn't matter). The reason is that find_in_files_dir is initialized to NULL and only set when you open a project and if the project is not open because msgwin_parse_grep_line() stops on
if (string == NULL || msgwindow.find_in_files_dir == NULL) return;
even though it might try to find the file when the provided path is absolute. I don't see any reason in this behaviour and the patch is pretty trivial.
Regards,
Jiri
Can you explain more about how you want to use these changes?
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Am 17.06.2010 22:56, schrieb Jiří Techet:
Hi Nick,
sure, the explanation follows next:
On Thu, Jun 17, 2010 at 16:28, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 9 Jun 2010 21:49:03 +0200 Jiří Techettechet@gmail.com wrote:
The following patches are required by gproject to build and run correctly. More details in the individual patches.
[PATCH 1/3] Add a signal that is emitted before build starts
I want to be able to save all project files before the build starts. Currently geany saves only the active file but does nothing with the other open files, so you may be compiling the old version. I think emitting the signal before build might be useful for other plugins too (e.g. if they pre-process the files before the build and so on)
Nothing against the signal, but I think saving all files should maybe done by Geany itself(?). Sounds like a bug to me.
Best regards.
On 18 June 2010 06:56, Jiří Techet techet@gmail.com wrote:
Hi Nick,
sure, the explanation follows next:
On Thu, Jun 17, 2010 at 16:28, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 9 Jun 2010 21:49:03 +0200 Jiří Techet techet@gmail.com wrote:
The following patches are required by gproject to build and run correctly. More details in the individual patches.
[PATCH 1/3] Add a signal that is emitted before build starts
I want to be able to save all project files before the build starts. Currently geany saves only the active file but does nothing with the other open files, so you may be compiling the old version. I think emitting the signal before build might be useful for other plugins too (e.g. if they pre-process the files before the build and so on)
I think that all files should always be saved when a build starts, manys the time I've edited both .h and then .c file, hit build and only the .c is saved. Gripe grump etc...
I remember there was some discussion about saving everything when I started the build system changes. I don't remember why it wasn't done. Can anyone think of a reason to not save all files? If no one can then I'll consider it a bug.
Cheers Lex
On Fri, 18 Jun 2010 08:20:42 +1000 Lex Trotman elextr@gmail.com wrote:
[PATCH 1/3] Add a signal that is emitted before build starts
I want to be able to save all project files before the build starts. Currently geany saves only the active file but does nothing with the other open files, so you may be compiling the old version. I think emitting the signal before build might be useful for other plugins too (e.g. if they pre-process the files before the build and so on)
I think that all files should always be saved when a build starts, manys the time I've edited both .h and then .c file, hit build and only the .c is saved. Gripe grump etc...
I remember there was some discussion about saving everything when I started the build system changes. I don't remember why it wasn't done. Can anyone think of a reason to not save all files? If no one can then I'll consider it a bug.
What if you didn't want all the files saved? I think it's safe to save the current file as the user is currently looking at it. But they may have modified other files they haven't decided to save yet.
Regards, Nick
On 18 June 2010 21:14, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Fri, 18 Jun 2010 08:20:42 +1000 Lex Trotman elextr@gmail.com wrote:
[PATCH 1/3] Add a signal that is emitted before build starts
I want to be able to save all project files before the build starts. Currently geany saves only the active file but does nothing with the other open files, so you may be compiling the old version. I think emitting the signal before build might be useful for other plugins too (e.g. if they pre-process the files before the build and so on)
I think that all files should always be saved when a build starts, manys the time I've edited both .h and then .c file, hit build and only the .c is saved. Gripe grump etc...
I remember there was some discussion about saving everything when I started the build system changes. I don't remember why it wasn't done. Can anyone think of a reason to not save all files? If no one can then I'll consider it a bug.
What if you didn't want all the files saved? I think it's safe to save the current file as the user is currently looking at it. But they may have modified other files they haven't decided to save yet.
Well until the Geany mind reading module is perfected... :-)
I guess the usual answer, add a preference setting. I really find it a @#$%^ nuisance when I forget to save all the files I want to compile :-(
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, 18 Jun 2010 21:42:59 +1000 Lex Trotman elextr@gmail.com wrote:
I remember there was some discussion about saving everything when I started the build system changes. I don't remember why it wasn't done. Can anyone think of a reason to not save all files? If no one can then I'll consider it a bug.
What if you didn't want all the files saved? I think it's safe to save the current file as the user is currently looking at it. But they may have modified other files they haven't decided to save yet.
Well until the Geany mind reading module is perfected... :-)
I guess the usual answer, add a preference setting. I really find it a @#$%^ nuisance when I forget to save all the files I want to compile :-(
I don't think it's a good pref for Geany to save all open files. This pref is perhaps better suited only for files in the current project's path.
Regards, Nick
On 19 June 2010 03:22, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Fri, 18 Jun 2010 21:42:59 +1000 Lex Trotman elextr@gmail.com wrote:
I remember there was some discussion about saving everything when I started the build system changes. I don't remember why it wasn't done. Can anyone think of a reason to not save all files? If no one can then I'll consider it a bug.
What if you didn't want all the files saved? I think it's safe to save the current file as the user is currently looking at it. But they may have modified other files they haven't decided to save yet.
Well until the Geany mind reading module is perfected... :-)
I guess the usual answer, add a preference setting. I really find it a @#$%^ nuisance when I forget to save all the files I want to compile :-(
I don't think it's a good pref for Geany to save all open files. This pref is perhaps better suited only for files in the current project's path.
Well, it should be at least the tree, not just the path, but the reason for the grouch above was that I had just done it *again*, and all I had was one .hpp and one .cpp, no project in sight.
In other words, I don't think its just project related, people who don't use projects are just as likely to make the mistake.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sat, 19 Jun 2010 08:22:07 +1000 Lex Trotman elextr@gmail.com wrote:
On 19 June 2010 03:22, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Fri, 18 Jun 2010 21:42:59 +1000 Lex Trotman elextr@gmail.com wrote:
I remember there was some discussion about saving everything when I started the build system changes. I don't remember why it wasn't done. Can anyone think of a reason to not save all files? If no one can then I'll consider it a bug.
What if you didn't want all the files saved? I think it's safe to save the current file as the user is currently looking at it. But they may have modified other files they haven't decided to save yet.
Well until the Geany mind reading module is perfected... :-)
I guess the usual answer, add a preference setting. I really find it a @#$%^ nuisance when I forget to save all the files I want to compile :-(
I don't think it's a good pref for Geany to save all open files. This pref is perhaps better suited only for files in the current project's path.
Well, it should be at least the tree, not just the path, but the reason for the grouch above was that I had just done it *again*, and all I had was one .hpp and one .cpp, no project in sight.
In other words, I don't think its just project related, people who don't use projects are just as likely to make the mistake.
I totally understand your intention behind, but not sure either whether its an good idea to save all session files at all. Shift-Ctrl-s is already doing something like this. Whether another option can help here I doubt, but why not. At least somebody has to build it ;)
Cheers, Frank
On 20 June 2010 03:37, Frank Lanitz frank@frank.uvena.de wrote:
On Sat, 19 Jun 2010 08:22:07 +1000 Lex Trotman elextr@gmail.com wrote:
On 19 June 2010 03:22, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Fri, 18 Jun 2010 21:42:59 +1000 Lex Trotman elextr@gmail.com wrote:
I remember there was some discussion about saving everything when I started the build system changes. I don't remember why it wasn't done. Can anyone think of a reason to not save all files? If no one can then I'll consider it a bug.
What if you didn't want all the files saved? I think it's safe to save the current file as the user is currently looking at it. But they may have modified other files they haven't decided to save yet.
Well until the Geany mind reading module is perfected... :-)
I guess the usual answer, add a preference setting. I really find it a @#$%^ nuisance when I forget to save all the files I want to compile :-(
I don't think it's a good pref for Geany to save all open files. This pref is perhaps better suited only for files in the current project's path.
Well, it should be at least the tree, not just the path, but the reason for the grouch above was that I had just done it *again*, and all I had was one .hpp and one .cpp, no project in sight.
In other words, I don't think its just project related, people who don't use projects are just as likely to make the mistake.
I totally understand your intention behind, but not sure either whether its an good idea to save all session files at all. Shift-Ctrl-s is already doing something like this. Whether another option can help here I doubt, but why not. At least somebody has to build it ;)
Well, since its related I'll include the option in the UI update to the build system.
Cheers Lex
Cheers, Frank -- http://frank.uvena.de/en/
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sat, Jun 19, 2010 at 00:22, Lex Trotman elextr@gmail.com wrote:
On 19 June 2010 03:22, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Fri, 18 Jun 2010 21:42:59 +1000 Lex Trotman elextr@gmail.com wrote:
I remember there was some discussion about saving everything when I started the build system changes. I don't remember why it wasn't done. Can anyone think of a reason to not save all files? If no one can then I'll consider it a bug.
What if you didn't want all the files saved? I think it's safe to save the current file as the user is currently looking at it. But they may have modified other files they haven't decided to save yet.
Well until the Geany mind reading module is perfected... :-)
I guess the usual answer, add a preference setting. I really find it a @#$%^ nuisance when I forget to save all the files I want to compile :-(
I don't think it's a good pref for Geany to save all open files. This pref is perhaps better suited only for files in the current project's path.
Well, it should be at least the tree, not just the path, but the reason for the grouch above was that I had just done it *again*, and all I had was one .hpp and one .cpp, no project in sight.
I agree that there should be an option in preferences. On the other hand, I understand that with how the geany project works it doesn't know what files belong to the project - the subtree starting from base_path may be a subset of the project and you have no way to tell whether an open file outside the tree belongs to the project or not. For gproject it's clear what files are included in the project (all files satisfying the given pattern inside a certain directory) so it makes more sense to do it by default there.
Cheers,
Jiri
In other words, I don't think its just project related, people who don't use projects are just as likely to make the mistake.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sun, 20 Jun 2010 17:08:40 +0200 Jiří Techet techet@gmail.com wrote:
On Sat, Jun 19, 2010 at 00:22, Lex Trotman elextr@gmail.com wrote:
On 19 June 2010 03:22, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Fri, 18 Jun 2010 21:42:59 +1000 Lex Trotman elextr@gmail.com wrote:
I remember there was some discussion about saving everything when I started the build system changes. I don't remember why it wasn't done. Can anyone think of a reason to not save all files? If no one can then I'll consider it a bug.
What if you didn't want all the files saved? I think it's safe to save the current file as the user is currently looking at it. But they may have modified other files they haven't decided to save yet.
Well until the Geany mind reading module is perfected... :-)
I guess the usual answer, add a preference setting. I really find it a @#$%^ nuisance when I forget to save all the files I want to compile :-(
I don't think it's a good pref for Geany to save all open files. This pref is perhaps better suited only for files in the current project's path.
Well, it should be at least the tree, not just the path, but the reason for the grouch above was that I had just done it *again*, and all I had was one .hpp and one .cpp, no project in sight.
I agree that there should be an option in preferences. On the other hand, I understand that with how the geany project works it doesn't know what files belong to the project - the subtree starting from base_path may be a subset of the project and you have no way to tell whether an open file outside the tree belongs to the project or not.
Yes, I agree. Lets do an practical example. We are renaming a function inside a file inside geany/tagmanager/include/*.h, but usage of the functions are e.g. in geany/tagmanager/*.c. Given the option is saving all files under geany/tagmanager/include/ we don't catch all possible changed and important files for the change where as we still have the risc of saving unwanted changes inside.
For gproject it's clear what files are included in the project (all files satisfying the given pattern inside a certain directory) so it makes more sense to do it by default there.
For a real project its worth to think about even I'm not sure whether I'd like it.
Thanks, Frank
I agree that there should be an option in preferences. On the other hand, I understand that with how the geany project works it doesn't know what files belong to the project - the subtree starting from base_path may be a subset of the project and you have no way to tell whether an open file outside the tree belongs to the project or not.
You are right, there is no way to tell, and it also has to work without a project so initially I am only going to offer the options save none, save current or save all.
Because of the way the build dialog is planned to operate it is actually easier to make this an option you can choose per menu item. This also makes it possible to choose to save all for the make commands and only save current for the compile commands if thats how you want it to operate.
Cheers Lex
PS Jiri, of course you can override these settings from your plugin so you can tell the builder not to save anything and then save whatever you want in the plugin when you get the build signal.
Yes, I agree. Lets do an practical example. We are renaming a function inside a file inside geany/tagmanager/include/*.h, but usage of the functions are e.g. in geany/tagmanager/*.c. Given the option is saving all files under geany/tagmanager/include/ we don't catch all possible changed and important files for the change where as we still have the risc of saving unwanted changes inside.
For gproject it's clear what files are included in the project (all files satisfying the given pattern inside a certain directory) so it makes more sense to do it by default there.
For a real project its worth to think about even I'm not sure whether I'd like it.
Thanks, Frank -- http://frank.uvena.de/en/
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Mon, 21 Jun 2010 08:57:16 +1000 Lex Trotman elextr@gmail.com wrote:
I agree that there should be an option in preferences. On the other hand, I understand that with how the geany project works it doesn't know what files belong to the project - the subtree starting from base_path may be a subset of the project and you have no way to tell whether an open file outside the tree belongs to the project or not.
The base path should be the root of all project files.
You are right, there is no way to tell, and it also has to work without a project so initially I am only going to offer the options save none, save current or save all.
Perhaps that is OK.
Because of the way the build dialog is planned to operate it is actually easier to make this an option you can choose per menu item. This also makes it possible to choose to save all for the make commands and only save current for the compile commands if thats how you want it to operate.
Lex, this makes the design too complex. A global pref would be enough.
Regards, Nick
On Mon, Jun 21, 2010 at 14:29, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Mon, 21 Jun 2010 08:57:16 +1000 Lex Trotman elextr@gmail.com wrote:
I agree that there should be an option in preferences. On the other hand, I understand that with how the geany project works it doesn't know what files belong to the project - the subtree starting from base_path may be a subset of the project and you have no way to tell whether an open file outside the tree belongs to the project or not.
The base path should be the root of all project files.
I believe the base path is the path where make (and other build commands) are called. I can set base path to build only one subsystem of the project so in this case not all project files will be located under this path.
You are right, there is no way to tell, and it also has to work without a project so initially I am only going to offer the options save none, save current or save all.
Perhaps that is OK.
Because of the way the build dialog is planned to operate it is actually easier to make this an option you can choose per menu item. This also makes it possible to choose to save all for the make commands and only save current for the compile commands if thats how you want it to operate.
Lex, this makes the design too complex. A global pref would be enough.
Agree with Nick here - this seems to be too complex and global option is just fine IMO.
Jiri
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Mon, 21 Jun 2010 18:41:11 +0200 Jiří Techet techet@gmail.com wrote:
The base path should be the root of all project files.
I believe the base path is the path where make (and other build commands) are called. I can set base path to build only one subsystem of the project so in this case not all project files will be located under this path.
You can setup make and other commands to build in any directory, e.g: %p/build
Regards, Nick
On 21 June 2010 22:29, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Mon, 21 Jun 2010 08:57:16 +1000 Lex Trotman elextr@gmail.com wrote:
I agree that there should be an option in preferences. On the other hand, I understand that with how the geany project works it doesn't know what files belong to the project - the subtree starting from base_path may be a subset of the project and you have no way to tell whether an open file outside the tree belongs to the project or not.
The base path should be the root of all project files.
Whilst I always do it this way (at least so far) the devil in me wants to know why this is a requirement?
You are right, there is no way to tell, and it also has to work without a project so initially I am only going to offer the options save none, save current or save all.
Perhaps that is OK.
Ok.
Because of the way the build dialog is planned to operate it is actually easier to make this an option you can choose per menu item. This also makes it possible to choose to save all for the make commands and only save current for the compile commands if thats how you want it to operate.
Lex, this makes the design too complex. A global pref would be enough.
It actually makes no difference to the implementation, all it changes is the dialog that the option is on, so if everyone is happy that a single global pref is acceptable from the user point of view then I'll do that.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, 22 Jun 2010 09:05:02 +1000 Lex Trotman elextr@gmail.com wrote:
On 21 June 2010 22:29, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Mon, 21 Jun 2010 08:57:16 +1000 Lex Trotman elextr@gmail.com wrote:
I agree that there should be an option in preferences. On the other hand, I understand that with how the geany project works it doesn't know what files belong to the project - the subtree starting from base_path may be a subset of the project and you have no way to tell whether an open file outside the tree belongs to the project or not.
The base path should be the root of all project files.
Whilst I always do it this way (at least so far) the devil in me wants to know why this is a requirement?
Because that's what it's called: *base* path. Everything that reads that path expects it to be the root. Of course you can set it to anything, but it would be less useful.
You are right, there is no way to tell, and it also has to work without a project so initially I am only going to offer the options save none, save current or save all.
Perhaps that is OK.
Ok.
Because of the way the build dialog is planned to operate it is actually easier to make this an option you can choose per menu item. This also makes it possible to choose to save all for the make commands and only save current for the compile commands if thats how you want it to operate.
Lex, this makes the design too complex. A global pref would be enough.
It actually makes no difference to the implementation, all it changes is the dialog that the option is on, so if everyone is happy that a single global pref is acceptable from the user point of view then I'll do that.
I'd rather not add options to the build dialog unless they are really wanted.
Regards, Nick
Am 18.06.2010 13:14, schrieb Nick Treleaven:
What if you didn't want all the files saved? I think it's safe to save the current file as the user is currently looking at it. But they may have modified other files they haven't decided to save yet.
Why save the current file then? Apparently saving is made due to the assumption that saving is needed for recompilation. So it makes sense to do it for all files. I believe all other IDEs save all files.
Best regards.
On Thu, 17 Jun 2010 22:56:06 +0200 Jiří Techet techet@gmail.com wrote:
[PATCH 1/3] Add a signal that is emitted before build starts
I want to be able to save all project files before the build starts. Currently geany saves only the active file but does nothing with the other open files, so you may be compiling the old version. I think emitting the signal before build might be useful for other plugins too (e.g. if they pre-process the files before the build and so on)
OK, I'll add the signal.
[PATCH 2/3] Make it possible to fill some fields of find in files dialog by plugins
There are two fields that I find it useful to pre-set in the find in files dialog:
- the path - my plugin displays a project file tree in the sidebar and
right-clicking a folder and selecting "find in directory" pre-fills the directory in the dialog for the user. This saves a lot of time especially when the directory structure is deep.
(The File Browser also does this).
- extra options - in my plugin the project files are defined by a set
of patterns, so by providing a base path and patterns like *.c;*.h;*.am he defines the files he'll see in the sidebar and that are "inside" the project. Search in project files applies only to these files (and for big projects you really don't want to search *.o and others) so you need to restrict grep by something like
--include=*.c --include=*.h --include=*.am
Unfortunately the more file types you have, the more typing it involves so the plugin does this for you.
I like the idea, but I'd rather not allow plugins to override the 'extra options' field - this is a user setting.
I think this feature could be part of Geany - we already have a (currently unused & hidden) 'patterns' field which is meant to hold something like "*.c;*.h;*.am".
Then we could add a FIF dialog checkbox 'Use project patterns'. That also allows the user to still do normal searches outside the project.
That option would also be useful to search files with no extension - README, ChangeLog, NEWS, etc without having to add all those filenames to the pattern.
I can imagine that other plugins might find it useful to change the "search for" field and that the "extra options" checkbox might be also plugin-settable so I could add those too if you wish.
I'd prefer to only add things when there is a good use case for them.
[PATCH 3/3] Open files from msgwindow even if find_in_files_dir is not set
Currently if you want to open a file by double clicking the filename in the msgwindow (e.g. after searching in files), the file is opened only after the project had been opened for the first time (subsequent closing the project doesn't matter). The reason is that find_in_files_dir is initialized to NULL and only set when you open a project and if the project is not open because msgwin_parse_grep_line() stops on
if (string == NULL || msgwindow.find_in_files_dir == NULL) return;
even though it might try to find the file when the provided path is absolute. I don't see any reason in this behaviour and the patch is pretty trivial.
I think the bug might be that msgwindow.find_in_files_dir somewhere didn't get set - I'll look into it.
Regards, Nick
On Fri, Jun 18, 2010 at 13:26, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 17 Jun 2010 22:56:06 +0200 Jiří Techet techet@gmail.com wrote:
[PATCH 1/3] Add a signal that is emitted before build starts
I want to be able to save all project files before the build starts. Currently geany saves only the active file but does nothing with the other open files, so you may be compiling the old version. I think emitting the signal before build might be useful for other plugins too (e.g. if they pre-process the files before the build and so on)
OK, I'll add the signal.
[PATCH 2/3] Make it possible to fill some fields of find in files dialog by plugins
There are two fields that I find it useful to pre-set in the find in files dialog:
- the path - my plugin displays a project file tree in the sidebar and
right-clicking a folder and selecting "find in directory" pre-fills the directory in the dialog for the user. This saves a lot of time especially when the directory structure is deep.
(The File Browser also does this).
I know, I just needed a function that sets both of them.
- extra options - in my plugin the project files are defined by a set
of patterns, so by providing a base path and patterns like *.c;*.h;*.am he defines the files he'll see in the sidebar and that are "inside" the project. Search in project files applies only to these files (and for big projects you really don't want to search *.o and others) so you need to restrict grep by something like
--include=*.c --include=*.h --include=*.am
Unfortunately the more file types you have, the more typing it involves so the plugin does this for you.
I like the idea, but I'd rather not allow plugins to override the 'extra options' field - this is a user setting.
I think this feature could be part of Geany - we already have a (currently unused & hidden) 'patterns' field which is meant to hold something like "*.c;*.h;*.am".
Then we could add a FIF dialog checkbox 'Use project patterns'. That also allows the user to still do normal searches outside the project.
That option would also be useful to search files with no extension - README, ChangeLog, NEWS, etc without having to add all those filenames to the pattern.
Yes, my patch was a quick hack how to introduce the functionality into geany without changing much of the code.
I like your idea in general, the only thing I don't like about it is that you wouldn't see the patterns in the FIF dialog, which would make it a bit unclear what you are searching for. I would propose to have a "file types" edit box that would be editable by the user even if no project is opened - this makes sense because users might want to search for restricted set of files even if they don't use any project. By default the pattern could be * to search in every file like now (empty edit box should do the same too). Then there would be the 'Use project patterns' you propose (not active when no project is open). When checked, the "file types" edit box would become inactive but filled with the project patterns so it would be visible directly in the dialog what the user is searching for. What do you think about it?
I can imagine that other plugins might find it useful to change the "search for" field and that the "extra options" checkbox might be also plugin-settable so I could add those too if you wish.
I'd prefer to only add things when there is a good use case for them.
[PATCH 3/3] Open files from msgwindow even if find_in_files_dir is not set
Currently if you want to open a file by double clicking the filename in the msgwindow (e.g. after searching in files), the file is opened only after the project had been opened for the first time (subsequent closing the project doesn't matter). The reason is that find_in_files_dir is initialized to NULL and only set when you open a project and if the project is not open because msgwin_parse_grep_line() stops on
if (string == NULL || msgwindow.find_in_files_dir == NULL) return;
even though it might try to find the file when the provided path is absolute. I don't see any reason in this behaviour and the patch is pretty trivial.
I think the bug might be that msgwindow.find_in_files_dir somewhere didn't get set - I'll look into it.
It's not a bug that msgwindow.find_in_files_dir is not set - I think it's correct that it's not set before you open a project. The problem is that when it's not set, the file in the msgwindow doesn't open when you click it even if there is a full path to that file (which doesn't require the find_in_files_dir)
Regards,
Jiri
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sun, 20 Jun 2010 17:24:48 +0200 Jiří Techet techet@gmail.com wrote:
On Fri, Jun 18, 2010 at 13:26, Nick Treleaven nick.treleaven@btinternet.com wrote:
Then we could add a FIF dialog checkbox 'Use project patterns'. That also allows the user to still do normal searches outside the project.
That option would also be useful to search files with no extension - README, ChangeLog, NEWS, etc without having to add all those filenames to the pattern.
I like your idea in general, the only thing I don't like about it is that you wouldn't see the patterns in the FIF dialog, which would make it a bit unclear what you are searching for. I would propose to have a "file types" edit box that would be editable by the user even if no project is opened - this makes sense because users might want to search for restricted set of files even if they don't use any project.
SciTE, Notepad++ and UltraEdit all have such a field, labeled "Files:", "Filters" and "In Files/Types" respectively.
Then we could add a FIF dialog checkbox 'Use project patterns'. That also allows the user to still do normal searches outside the project.
That option would also be useful to search files with no extension - README, ChangeLog, NEWS, etc without having to add all those filenames to the pattern.
Yes, my patch was a quick hack how to introduce the functionality into geany without changing much of the code.
I like your idea in general, the only thing I don't like about it is that you wouldn't see the patterns in the FIF dialog, which would make it a bit unclear what you are searching for. I would propose to have a "file types" edit box that would be editable by the user even if no project is opened - this makes sense because users might want to search for restricted set of files even if they don't use any project. By default the pattern could be * to search in every file like now (empty edit box should do the same too). Then there would be the 'Use project patterns' you propose (not active when no project is open). When checked, the "file types" edit box would become inactive but filled with the project patterns so it would be visible directly in the dialog what the user is searching for. What do you think about it?
Having a filetype pattern in the find in files dialog could be useful. Note that --include is a GNU grep extension, so a blank file pattern should be the default and should not generate the option to grep so as to maintain portability.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Mon, 21 Jun 2010 08:47:54 +1000 Lex Trotman elextr@gmail.com wrote:
I like your idea in general, the only thing I don't like about it is that you wouldn't see the patterns in the FIF dialog, which would make it a bit unclear what you are searching for. I would propose to have a "file types" edit box that would be editable by the user even if no project is opened - this makes sense because users might want to search for restricted set of files even if they don't use any project. By default the pattern could be * to search in every file like now (empty edit box should do the same too). Then there would be the 'Use project patterns' you propose (not active when no project is open). When checked, the "file types" edit box would become inactive but filled with the project patterns so it would be visible directly in the dialog what the user is searching for. What do you think about it?
Sounds good.
Having a filetype pattern in the find in files dialog could be useful. Note that --include is a GNU grep extension, so a blank file pattern should be the default and should not generate the option to grep so as to maintain portability.
Geany currently passes a list of all files and directories to Grep. I think it may be best if Geany does the filtering (and hence also the recursing). Also we may want to always filter out hidden files and broken links.
Regards, Nick
On Mon, Jun 21, 2010 at 16:08, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Mon, 21 Jun 2010 08:47:54 +1000 Lex Trotman elextr@gmail.com wrote:
I like your idea in general, the only thing I don't like about it is that you wouldn't see the patterns in the FIF dialog, which would make it a bit unclear what you are searching for. I would propose to have a "file types" edit box that would be editable by the user even if no project is opened - this makes sense because users might want to search for restricted set of files even if they don't use any project. By default the pattern could be * to search in every file like now (empty edit box should do the same too). Then there would be the 'Use project patterns' you propose (not active when no project is open). When checked, the "file types" edit box would become inactive but filled with the project patterns so it would be visible directly in the dialog what the user is searching for. What do you think about it?
Sounds good.
Having a filetype pattern in the find in files dialog could be useful. Note that --include is a GNU grep extension, so a blank file pattern should be the default and should not generate the option to grep so as to maintain portability.
Geany currently passes a list of all files and directories to Grep. I
Does it? To me it looks it only calls grep in the given directory.
think it may be best if Geany does the filtering (and hence also the recursing). Also we may want to always filter out hidden files and broken links.
There is one problem here - the command line may be too long. By posix ARG_MAX is at least 4096 but this will be definitely too little for thousands of files. There are three options how to solve this:
1. Call grep separately for every single file. This is too slow. I tested something like that some time ago and for about 10000 source files it takes 30 seconds just to execute grep so many times. To find e.g. "torvalds" in all *.c;*.h files of linux kernel using -r and --include it takes only 2 seconds (the first search is always slow because the files have to be read from disk, but any subsequent search is really fast as the files are cached by the OS). The speed is very important for me.
2. Use xargs - this introduces one more external dependency for geany so it probably isn't the preferable solution.
3. Implement some alternative to xargs and call grep repeatably only for as many files that can be passed on command line.
Only (3) seems to be a reasonable solution but it means some extra work. Right now I find the easiest way to implement it using --include - if no pattern or * pattern is specified, --include will be omitted (as Lex suggested) and no error reported if the grep doesn't support it.
Regards,
Jiri
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Mon, 21 Jun 2010 20:53:58 +0200 Jiří Techet techet@gmail.com wrote:
Having a filetype pattern in the find in files dialog could be useful. Note that --include is a GNU grep extension, so a blank file pattern should be the default and should not generate the option to grep so as to maintain portability.
Geany currently passes a list of all files and directories to Grep. I
Does it? To me it looks it only calls grep in the given directory.
If the -r (GNU extension) recursive option is set, it just passes '.' as the path instead of any filenames.
Without -r, I'm not sure how to call Grep without passing a list of files. Maybe I'm missing something, but that was why I implemented passing all filenames. (See how search_get_argv() is used).
think it may be best if Geany does the filtering (and hence also the recursing). Also we may want to always filter out hidden files and broken links.
There is one problem here - the command line may be too long. By posix ARG_MAX is at least 4096 but this will be definitely too little for thousands of files. There are three options how to solve this:
- Call grep separately for every single file. This is too slow. I
tested something like that some time ago and for about 10000 source files it takes 30 seconds just to execute grep so many times. To find e.g. "torvalds" in all *.c;*.h files of linux kernel using -r and --include it takes only 2 seconds (the first search is always slow because the files have to be read from disk, but any subsequent search is really fast as the files are cached by the OS). The speed is very important for me.
- Use xargs - this introduces one more external dependency for geany
so it probably isn't the preferable solution.
- Implement some alternative to xargs and call grep repeatably only
for as many files that can be passed on command line.
Only (3) seems to be a reasonable solution but it means some extra work. Right now I find the easiest way to implement it using --include
- if no pattern or * pattern is specified, --include will be omitted
(as Lex suggested) and no error reported if the grep doesn't support it.
AFAICT, you still have to pass filenames even when using --include (when non-recursive).
Personally we've not had complaints about the argument length limit, so I'm not too bothered about it yet. Also modern systems may extend the POSIX limit, but obviously we can't rely on that. Maybe wait and see if it's a problem?
Regards, Nick
On Tue, Jun 22, 2010 at 13:46, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Mon, 21 Jun 2010 20:53:58 +0200 Jiří Techet techet@gmail.com wrote:
Having a filetype pattern in the find in files dialog could be useful. Note that --include is a GNU grep extension, so a blank file pattern should be the default and should not generate the option to grep so as to maintain portability.
Geany currently passes a list of all files and directories to Grep. I
Does it? To me it looks it only calls grep in the given directory.
If the -r (GNU extension) recursive option is set, it just passes '.' as the path instead of any filenames.
Without -r, I'm not sure how to call Grep without passing a list of files. Maybe I'm missing something, but that was why I implemented passing all filenames. (See how search_get_argv() is used).
I see, you meant the non-recursive version.
think it may be best if Geany does the filtering (and hence also the recursing). Also we may want to always filter out hidden files and broken links.
There is one problem here - the command line may be too long. By posix ARG_MAX is at least 4096 but this will be definitely too little for thousands of files. There are three options how to solve this:
- Call grep separately for every single file. This is too slow. I
tested something like that some time ago and for about 10000 source files it takes 30 seconds just to execute grep so many times. To find e.g. "torvalds" in all *.c;*.h files of linux kernel using -r and --include it takes only 2 seconds (the first search is always slow because the files have to be read from disk, but any subsequent search is really fast as the files are cached by the OS). The speed is very important for me.
- Use xargs - this introduces one more external dependency for geany
so it probably isn't the preferable solution.
- Implement some alternative to xargs and call grep repeatably only
for as many files that can be passed on command line.
Only (3) seems to be a reasonable solution but it means some extra work. Right now I find the easiest way to implement it using --include
- if no pattern or * pattern is specified, --include will be omitted
(as Lex suggested) and no error reported if the grep doesn't support it.
AFAICT, you still have to pass filenames even when using --include (when non-recursive).
Personally we've not had complaints about the argument length limit, so I'm not too bothered about it yet. Also modern systems may extend the POSIX limit, but obviously we can't rely on that. Maybe wait and see if it's a problem?
The problem is already here for big projects. You don't see it if you call it for a single directory - the number of files in one directory isn't usually so huge but if you recursively search the whole project directory structure, you may get a lot of source files. At work I use SLES9 which has ARG_MAX=131072 and the project has about 8000 source files. If you assume the path is about 40 characters (can be more with projects with deep directory structure), you get 8000*40=320000 and you're over the limit.
Personally I find using the gnu extensions much more safe. After looking at grep's git history, I found that --include was introduced in 2001 (GTK 2 didn't exist at that time and linux kernel 2.4 was just freshly released). On the other hand the ARG_MAX limit was increased quite recently in kernel 2.6.23 in 2007 (see http://www.in-ulm.de/~mascheck/various/argmax/ to see the limits for other platforms) and older kernels are still in use. I'm also not aware of any non-gnu implementations of grep (that might not implement --include).
To me it looks much easier to use what's already present in grep right now and if this isn't satisfactory, it could be reimplemented the way you propose in the future. In addition if no patterns are specified, geany will behave the same way it did until now so there is a sane fallback solution for people with very old grep.
Regards,
Jiri
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, 22 Jun 2010 15:19:02 +0200 Jiří Techet techet@gmail.com wrote:
think it may be best if Geany does the filtering (and hence also the recursing). Also we may want to always filter out hidden files and broken links.
There is one problem here - the command line may be too long. By posix ARG_MAX is at least 4096 but this will be definitely too little for thousands of files. There are three options how to solve this:
...
- Implement some alternative to xargs and call grep repeatably only
for as many files that can be passed on command line.
Only (3) seems to be a reasonable solution but it means some extra work. Right now I find the easiest way to implement it using --include
- if no pattern or * pattern is specified, --include will be omitted
(as Lex suggested) and no error reported if the grep doesn't support it.
AFAICT, you still have to pass filenames even when using --include (when non-recursive).
Personally we've not had complaints about the argument length limit, so I'm not too bothered about it yet. Also modern systems may extend the POSIX limit, but obviously we can't rely on that. Maybe wait and see if it's a problem?
The problem is already here for big projects. You don't see it if you call it for a single directory - the number of files in one directory isn't usually so huge but if you recursively search the whole project directory structure, you may get a lot of source files. At work I use SLES9 which has ARG_MAX=131072 and the project has about 8000 source files. If you assume the path is about 40 characters (can be more with projects with deep directory structure), you get 8000*40=320000 and you're over the limit.
OK, so we should keep the current behaviour of not passing filenames for a recursive grep.
Personally I find using the gnu extensions much more safe. After looking at grep's git history, I found that --include was introduced in 2001 (GTK 2 didn't exist at that time and linux kernel 2.4 was just freshly released). On the other hand the ARG_MAX limit was increased quite recently in kernel 2.6.23 in 2007 (see http://www.in-ulm.de/~mascheck/various/argmax/ to see the limits for other platforms) and older kernels are still in use. I'm also not aware of any non-gnu implementations of grep (that might not implement --include).
To me it looks much easier to use what's already present in grep right now and if this isn't satisfactory, it could be reimplemented the way you propose in the future. In addition if no patterns are specified, geany will behave the same way it did until now so there is a sane fallback solution for people with very old grep.
Let's use --include then if the user ticks a checkbox. That way a non-gnu system will still be able to do non-recursive all files search.
Regards, Nick
On Tue, 22 Jun 2010 16:48:29 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
To me it looks much easier to use what's already present in grep right now and if this isn't satisfactory, it could be reimplemented the way you propose in the future. In addition if no patterns are specified, geany will behave the same way it did until now so there is a sane fallback solution for people with very old grep.
Let's use --include then if the user ticks a checkbox. That way a non-gnu system will still be able to do non-recursive all files search.
BTW I've just added a dummy Files checkbox and combobox to the dialog in SVN, and will continue tomorrow (unless anyone objects).
Regards, Nick
On 23 June 2010 02:54, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Tue, 22 Jun 2010 16:48:29 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
To me it looks much easier to use what's already present in grep right now and if this isn't satisfactory, it could be reimplemented the way you propose in the future. In addition if no patterns are specified, geany will behave the same way it did until now so there is a sane fallback solution for people with very old grep.
Let's use --include then if the user ticks a checkbox. That way a non-gnu system will still be able to do non-recursive all files search.
BTW I've just added a dummy Files checkbox and combobox to the dialog in SVN, and will continue tomorrow (unless anyone objects).
I think this is a good solution, it uses grep's capabilities if available and still does useful things if grep is brain dead
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, Jun 22, 2010 at 18:54, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Tue, 22 Jun 2010 16:48:29 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
To me it looks much easier to use what's already present in grep right now and if this isn't satisfactory, it could be reimplemented the way you propose in the future. In addition if no patterns are specified, geany will behave the same way it did until now so there is a sane fallback solution for people with very old grep.
Let's use --include then if the user ticks a checkbox. That way a non-gnu system will still be able to do non-recursive all files search.
BTW I've just added a dummy Files checkbox and combobox to the dialog in SVN, and will continue tomorrow (unless anyone objects).
Ah, great, I thought I was the one who was supposed to implement this :-). I'll happily leave the joy of the implementation to anyone else because I'm pretty busy now...
Jiri
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, 23 Jun 2010 22:57:00 +0200 Jiří Techet techet@gmail.com wrote:
Let's use --include then if the user ticks a checkbox. That way a non-gnu system will still be able to do non-recursive all files search.
BTW I've just added a dummy Files checkbox and combobox to the dialog in SVN, and will continue tomorrow (unless anyone objects).
Ah, great, I thought I was the one who was supposed to implement this :-). I'll happily leave the joy of the implementation to anyone else because I'm pretty busy now...
I wanted the Files box to be there and wanted to tidy up some things in the GUI code so that's done now.
I probably won't add a 'Use project patterns' checkbox for a while so patches are welcome.
Regards, Nick
On Thu, Jun 24, 2010 at 15:50, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 23 Jun 2010 22:57:00 +0200 Jiří Techet techet@gmail.com wrote:
Let's use --include then if the user ticks a checkbox. That way a non-gnu system will still be able to do non-recursive all files search.
BTW I've just added a dummy Files checkbox and combobox to the dialog in SVN, and will continue tomorrow (unless anyone objects).
Ah, great, I thought I was the one who was supposed to implement this :-). I'll happily leave the joy of the implementation to anyone else because I'm pretty busy now...
I wanted the Files box to be there and wanted to tidy up some things in the GUI code so that's done now.
Looks good. I was just wondering about what separator should be used to separate the individual patterns - in gproject I used semicolon because this makes it consistent with filetype_extensions.conf. What's the reason for using space (readability, some other settings that uses spaces or something else)? If you decide for space I'll change gproject to make it consistent with the FIF dialog.
I probably won't add a 'Use project patterns' checkbox for a while so patches are welcome.
I'll do that. I've already modified gproject to make it easier to integrate it with current geany project and after modifying geany, I'll send all the necessary patches together.
Cheers,
Jiri
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, 25 Jun 2010 14:32:38 +0200 Jiří Techet techet@gmail.com wrote:
I wanted the Files box to be there and wanted to tidy up some things in the GUI code so that's done now.
Looks good. I was just wondering about what separator should be used to separate the individual patterns - in gproject I used semicolon because this makes it consistent with filetype_extensions.conf. What's the reason for using space (readability, some other settings that uses spaces or something else)? If you decide for space I'll change gproject to make it consistent with the FIF dialog.
Readability - it's a GUI setting. SciTE does it like that and it looks good.
I probably won't add a 'Use project patterns' checkbox for a while so patches are welcome.
I'll do that. I've already modified gproject to make it easier to integrate it with current geany project and after modifying geany, I'll send all the necessary patches together.
I'm not sure what gproject wants to do with this, I assumed Geany's Project Properties dialog 'patterns' field would be used rather than changing the API, so it would be a core feature rather than gproject. What do you have in mind?
Regards, Nick
On Fri, Jun 25, 2010 at 17:31, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Fri, 25 Jun 2010 14:32:38 +0200 Jiří Techet techet@gmail.com wrote:
I wanted the Files box to be there and wanted to tidy up some things in the GUI code so that's done now.
Looks good. I was just wondering about what separator should be used to separate the individual patterns - in gproject I used semicolon because this makes it consistent with filetype_extensions.conf. What's the reason for using space (readability, some other settings that uses spaces or something else)? If you decide for space I'll change gproject to make it consistent with the FIF dialog.
Readability - it's a GUI setting. SciTE does it like that and it looks good.
OK.
I probably won't add a 'Use project patterns' checkbox for a while so patches are welcome.
I'll do that. I've already modified gproject to make it easier to integrate it with current geany project and after modifying geany, I'll send all the necessary patches together.
I'm not sure what gproject wants to do with this, I assumed Geany's Project Properties dialog 'patterns' field would be used rather than changing the API, so it would be a core feature rather than gproject. What do you have in mind?
In gproject I have three kinds of patterns - header file patterns, source file patterns and others file patterns (see the original announcement email to see what I use them for). For search I want to use all of these patterns. Of course it would be possible for the user to manually copy and paste all of these patterns to another edit box, but this is not really nice from the user perspective. So I'd like to be able to define the patterns used for search from within gproject.
Regards,
Jiri
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 22 June 2010 00:08, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Mon, 21 Jun 2010 08:47:54 +1000 Lex Trotman elextr@gmail.com wrote:
I like your idea in general, the only thing I don't like about it is that you wouldn't see the patterns in the FIF dialog, which would make it a bit unclear what you are searching for. I would propose to have a "file types" edit box that would be editable by the user even if no project is opened - this makes sense because users might want to search for restricted set of files even if they don't use any project. By default the pattern could be * to search in every file like now (empty edit box should do the same too). Then there would be the 'Use project patterns' you propose (not active when no project is open). When checked, the "file types" edit box would become inactive but filled with the project patterns so it would be visible directly in the dialog what the user is searching for. What do you think about it?
Sounds good.
Having a filetype pattern in the find in files dialog could be useful. Note that --include is a GNU grep extension, so a blank file pattern should be the default and should not generate the option to grep so as to maintain portability.
Geany currently passes a list of all files and directories to Grep. I think it may be best if Geany does the filtering (and hence also the recursing). Also we may want to always filter out hidden files and broken links.
That would be the best way since then there could be full control (and of course you would prevent infinite loops due to cycles in the filestructure :-). But it would be way more work, also currently the file/directory list is not expanded if the recurse option is set. I'd do it Jiri's way for now and use --include so long as its not the default.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sun, 20 Jun 2010 17:24:48 +0200 Jiří Techet techet@gmail.com wrote:
[PATCH 3/3] Open files from msgwindow even if find_in_files_dir is not set
Currently if you want to open a file by double clicking the filename in the msgwindow (e.g. after searching in files), the file is opened only after the project had been opened for the first time (subsequent closing the project doesn't matter). The reason is that find_in_files_dir is initialized to NULL and only set when you open a project and if the project is not open because msgwin_parse_grep_line() stops on
if (string == NULL || msgwindow.find_in_files_dir == NULL) return;
even though it might try to find the file when the provided path is absolute. I don't see any reason in this behaviour and the patch is pretty trivial.
I think the bug might be that msgwindow.find_in_files_dir somewhere didn't get set - I'll look into it.
It's not a bug that msgwindow.find_in_files_dir is not set - I think it's correct that it's not set before you open a project. The problem is that when it's not set, the file in the msgwindow doesn't open when you click it even if there is a full path to that file (which doesn't require the find_in_files_dir)
Sorry for the late reply.
It's confusing that you talk about projects - msgwindow.find_in_files_dir has nothing to do with them, and is set when using Find in Files.
I applied your patch though so that plugins can add messages before FIF is used. Although if a plugin is doing that then we should probably add a function to set msgwindow.find_in_files_dir (and also rename it to messages_dir) so plugins don't have to use absolute paths.
Regards, Nick
On Fri, Jul 2, 2010 at 14:48, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Sun, 20 Jun 2010 17:24:48 +0200 Jiří Techet techet@gmail.com wrote:
[PATCH 3/3] Open files from msgwindow even if find_in_files_dir is not set
Currently if you want to open a file by double clicking the filename in the msgwindow (e.g. after searching in files), the file is opened only after the project had been opened for the first time (subsequent closing the project doesn't matter). The reason is that find_in_files_dir is initialized to NULL and only set when you open a project and if the project is not open because msgwin_parse_grep_line() stops on
if (string == NULL || msgwindow.find_in_files_dir == NULL) return;
even though it might try to find the file when the provided path is absolute. I don't see any reason in this behaviour and the patch is pretty trivial.
I think the bug might be that msgwindow.find_in_files_dir somewhere didn't get set - I'll look into it.
It's not a bug that msgwindow.find_in_files_dir is not set - I think it's correct that it's not set before you open a project. The problem is that when it's not set, the file in the msgwindow doesn't open when you click it even if there is a full path to that file (which doesn't require the find_in_files_dir)
Sorry for the late reply.
It's confusing that you talk about projects - msgwindow.find_in_files_dir has nothing to do with them, and is set when using Find in Files.
I applied your patch though so that plugins can add messages before FIF is used. Although if a plugin is doing that then we should probably add a function to set msgwindow.find_in_files_dir (and also rename it to messages_dir) so plugins don't have to use absolute paths.
Actually I already did the very same thing :-) - I just used different name than messages_dir, but messages_dir is better than the name I used so I'll rename it. I've also modified gproject to extend the current project functionality rather than replacing it and made several more changes that fix/improve functionality of geany. I'm just not sure how to send the patches - many of them change something in project.c so they depend on each other. Do you prefer to send them to the mailing list (but then you have to apply them in the right order) or is it enough if I publish them in the form of public git repository (easier for me and easier for you too I believe).
Regards,
Jiri
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, 2 Jul 2010 15:15:44 +0200 Jiří Techet techet@gmail.com wrote:
I applied your patch though so that plugins can add messages before FIF is used. Although if a plugin is doing that then we should probably add a function to set msgwindow.find_in_files_dir (and also rename it to messages_dir) so plugins don't have to use absolute paths.
Actually I already did the very same thing :-) - I just used different name than messages_dir, but messages_dir is better than the name I used so I'll rename it. I've also modified gproject to extend the current project functionality rather than replacing it and made several more changes that fix/improve functionality of geany. I'm just not sure how to send the patches - many of them change something in project.c so they depend on each other. Do you prefer to send them to the mailing list (but then you have to apply them in the right order) or is it enough if I publish them in the form of public git repository (easier for me and easier for you too I believe).
I'd prefer patches, but I don't mind looking at some Git commits first to save the bother of redoing patches in case anything should be changed.
Regards, Nick