From morgan.stephen99 at gmail.com Fri Jan 7 18:45:48 2011 From: morgan.stephen99 at gmail.com (Stephen Morgan) Date: Fri, 07 Jan 2011 20:45:48 +0200 Subject: [Vimprobable-users] [PATCH 1/1] Add field for customising HTTP Accept-Language header Message-ID: <4D275F5C.4010501@gmail.com> The accept-language string must be coded into the config.h file in this setup, as WebKit doesn't seem to want to handle it like it does the user-agent string. --- config.h | 1 + main.c | 2 ++ 2 files changed, 3 insertions(+), 0 deletions(-) diff --git a/config.h b/config.h index e0290d3..7d96adb 100644 --- a/config.h +++ b/config.h @@ -14,6 +14,7 @@ /* general settings */ char startpage[1024] = "http://www.vimprobable.org/"; char useragent[1024] = "Vimprobable2/" VERSION; +char acceptlanguage[1024] = ""; static const gboolean enablePlugins = TRUE; /* TRUE keeps plugins enabled */ static const gboolean enableJava = TRUE; /* FALSE disables Java applets */ diff --git a/main.c b/main.c index 95ad0cd..4ba0338 100644 --- a/main.c +++ b/main.c @@ -2079,6 +2079,8 @@ setup_settings() { g_object_get((GObject*)settings, "zoom-step", &zoomstep, NULL); webkit_web_view_set_settings(webview, settings); + g_object_set(session, "accept-language", acceptlanguage, NULL); + /* proxy */ if (use_proxy == TRUE) { filename = (char *)g_getenv("http_proxy"); -- 1.7.2.2 From thomas at xteddy.org Fri Jan 7 18:55:54 2011 From: thomas at xteddy.org (Thomas Adam) Date: Fri, 7 Jan 2011 18:55:54 +0000 Subject: [Vimprobable-users] [PATCH 1/1] Add field for customising HTTP Accept-Language header In-Reply-To: <4D275F5C.4010501@gmail.com> References: <4D275F5C.4010501@gmail.com> Message-ID: <20110107185552.GA2022@debian> Hello, On Fri, Jan 07, 2011 at 08:45:48PM +0200, Stephen Morgan wrote: > > The accept-language string must be coded into the config.h file in this > setup, as WebKit doesn't seem to want to handle it like it does the > user-agent string. Sure -- it's nothing to do with webkit, and wholly a libsoup problem which means if the client (Vimprobable) wants to track it and/or set values for it, then it must be handled outside of anything to do with webkit. Thankfully, we do support that. :) > --- > config.h | 1 + > main.c | 2 ++ > 2 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/config.h b/config.h > index e0290d3..7d96adb 100644 > --- a/config.h > +++ b/config.h > @@ -14,6 +14,7 @@ > /* general settings */ > char startpage[1024] = "http://www.vimprobable.org/"; > char useragent[1024] = "Vimprobable2/" VERSION; > +char acceptlanguage[1024] = ""; This does want to be here, that's fine -- and I would say we should add an option to process_set_line (and the corresponding browersettings struct in config.h) for: :set acceptlanguage Which can the accept whatever we like. Making it blank by default is fine, and limiting ourselves to 1024 characters is proabably OK too, although > static const gboolean enablePlugins = TRUE; /* TRUE keeps plugins enabled */ > static const gboolean enableJava = TRUE; /* FALSE disables Java applets */ > > diff --git a/main.c b/main.c > index 95ad0cd..4ba0338 100644 > --- a/main.c > +++ b/main.c > @@ -2079,6 +2079,8 @@ setup_settings() { > g_object_get((GObject*)settings, "zoom-step", &zoomstep, NULL); > webkit_web_view_set_settings(webview, settings); > > + g_object_set(session, "accept-language", acceptlanguage, NULL); No -- this isn't right here. Please add this to setup_signals() which is called from main() anyway. Other than that, it looks good, thanks. -- Thomas Adam -- "It was the cruelest game I've ever played and it's played inside my head." -- "Hush The Warmth", Gorky's Zygotic Mynci. From morgan.stephen99 at gmail.com Fri Jan 7 21:25:45 2011 From: morgan.stephen99 at gmail.com (Stephen Morgan) Date: Fri, 07 Jan 2011 23:25:45 +0200 Subject: [Vimprobable-users] [PATCH 1/1] Add field for customising HTTP Accept-Language header In-Reply-To: <20110107185552.GA2022@debian> References: <4D275F5C.4010501@gmail.com> <20110107185552.GA2022@debian> Message-ID: <4D2784D9.7050200@gmail.com> Hi, Here's attempt #2, with the corrections and improvements you mentioned. Best, Stephen Morgan --- config.h | 2 ++ main.c | 8 ++++++++ vimprobablerc.1 | 3 +++ 3 files changed, 13 insertions(+), 0 deletions(-) diff --git a/config.h b/config.h index e0290d3..c252771 100644 --- a/config.h +++ b/config.h @@ -14,6 +14,7 @@ /* general settings */ char startpage[1024] = "http://www.vimprobable.org/"; char useragent[1024] = "Vimprobable2/" VERSION; +char acceptlanguage[1024] = ""; static const gboolean enablePlugins = TRUE; /* TRUE keeps plugins enabled */ static const gboolean enableJava = TRUE; /* FALSE disables Java applets */ @@ -172,6 +173,7 @@ static Setting browsersettings[] = { { "statuscolor", statuscolor, "", FALSE, FALSE, TRUE, TRUE }, { "sslbgcolor", sslbgcolor, "", FALSE, FALSE, TRUE, TRUE }, { "sslcolor", sslcolor, "", FALSE, FALSE, TRUE, TRUE }, + { "acceptlanguage", acceptlanguage, "", FALSE, FALSE, FALSE, FALSE }, { "qmark", NULL, "", FALSE, FALSE, FALSE, FALSE }, { "proxy", NULL, "", FALSE, TRUE, FALSE, FALSE }, { "scrollbars", NULL, "", FALSE, TRUE, FALSE, FALSE }, diff --git a/main.c b/main.c index 95ad0cd..f6252fa 100644 --- a/main.c +++ b/main.c @@ -1689,6 +1689,12 @@ process_set_line(char *line) { /* mandatory argument not provided */ if (strlen(my_pair.value) == 0) return FALSE; + /* process acceptlanguage */ + if (strlen(my_pair.what) == 14 && strncmp("acceptlanguage", my_pair.what, 14) == 0) { + strncpy(acceptlanguage, my_pair.value, strlen(my_pair.value) + 1); + g_object_set((GObject*)session, "accept-language", acceptlanguage, NULL); + return TRUE; + } /* process qmark? */ if (strlen(my_pair.what) == 5 && strncmp("qmark", my_pair.what, 5) == 0) { return (process_save_qmark(my_pair.value, webview)); @@ -2103,6 +2109,8 @@ setup_signals() { /* Headers. */ g_signal_connect_after((GObject*)session, "request-started", (GCallback)new_generic_request, NULL); #endif + /* Accept-language header */ + g_object_set((GObject*)session, "accept-language", acceptlanguage, NULL); /* window */ g_object_connect((GObject*)window, "signal::destroy", (GCallback)window_destroyed_cb, NULL, diff --git a/vimprobablerc.1 b/vimprobablerc.1 index 6494ff8..4d6b30c 100644 --- a/vimprobablerc.1 +++ b/vimprobablerc.1 @@ -65,6 +65,9 @@ Set the URL of the homepage. .IP useragent= Replace the default useragent-string. +.IP acceptlanguage= +Replace the default acceptlanguage-string. + .IP scripts=[true|false] Enable or disable scripts. -- 1.7.2.2 Le 07/01/11 08:55 PM, Thomas Adam a ?crit : > Hello, > > On Fri, Jan 07, 2011 at 08:45:48PM +0200, Stephen Morgan wrote: >> The accept-language string must be coded into the config.h file in this >> setup, as WebKit doesn't seem to want to handle it like it does the >> user-agent string. > Sure -- it's nothing to do with webkit, and wholly a libsoup problem which > means if the client (Vimprobable) wants to track it and/or set values for > it, then it must be handled outside of anything to do with webkit. > Thankfully, we do support that. :) > >> --- >> config.h | 1 + >> main.c | 2 ++ >> 2 files changed, 3 insertions(+), 0 deletions(-) >> >> diff --git a/config.h b/config.h >> index e0290d3..7d96adb 100644 >> --- a/config.h >> +++ b/config.h >> @@ -14,6 +14,7 @@ >> /* general settings */ >> char startpage[1024] = "http://www.vimprobable.org/"; >> char useragent[1024] = "Vimprobable2/" VERSION; >> +char acceptlanguage[1024] = ""; > This does want to be here, that's fine -- and I would say we should add an > option to process_set_line (and the corresponding browersettings struct in > config.h) for: > > :set acceptlanguage > > Which can the accept whatever we like. Making it blank by default is fine, > and limiting ourselves to 1024 characters is proabably OK too, although > >> static const gboolean enablePlugins = TRUE; /* TRUE keeps plugins enabled */ >> static const gboolean enableJava = TRUE; /* FALSE disables Java applets */ >> >> diff --git a/main.c b/main.c >> index 95ad0cd..4ba0338 100644 >> --- a/main.c >> +++ b/main.c >> @@ -2079,6 +2079,8 @@ setup_settings() { >> g_object_get((GObject*)settings, "zoom-step", &zoomstep, NULL); >> webkit_web_view_set_settings(webview, settings); >> >> + g_object_set(session, "accept-language", acceptlanguage, NULL); > No -- this isn't right here. Please add this to setup_signals() which is > called from main() anyway. > > Other than that, it looks good, thanks. > > -- Thomas Adam > From thomas at xteddy.org Fri Jan 7 21:31:27 2011 From: thomas at xteddy.org (Thomas Adam) Date: Fri, 7 Jan 2011 21:31:27 +0000 Subject: [Vimprobable-users] [PATCH 1/1] Add field for customising HTTP Accept-Language header In-Reply-To: <4D2784D9.7050200@gmail.com> References: <4D275F5C.4010501@gmail.com> <20110107185552.GA2022@debian> <4D2784D9.7050200@gmail.com> Message-ID: <20110107213125.GA2109@debian> On Fri, Jan 07, 2011 at 11:25:45PM +0200, Stephen Morgan wrote: > Hi, > > Here's attempt #2, with the corrections and improvements you mentioned. This looks fine at a cursive glance, thanks. However, this will now legitimately allow one to do: :set acceptlanguage Whereby entering no value would be just that -- unsetting any previous value. This is fine, but it will need documenting as such in the man page, please. Otherwise it looks fine. -- Thomas Adam -- "It was the cruelest game I've ever played and it's played inside my head." -- "Hush The Warmth", Gorky's Zygotic Mynci. From thomas at xteddy.org Fri Jan 7 22:25:12 2011 From: thomas at xteddy.org (Thomas Adam) Date: Fri, 7 Jan 2011 22:25:12 +0000 Subject: [Vimprobable-users] [PATCH 0/3] Cast pointer to macros for type-safety Message-ID: <20110107222508.GA7641@debian> Hi, This is one of many clean-up patches I've got lying around. This one is to convert stray casts to use macros where appropriate -- especially with the GTK stuff. Thomas Adam (3): Change all GObject cats to G_OBJECT Avoid GCallback* casts and use G_CALLBACK macro Cast other misc GtkFoo* pointers to macros main.c | 80 ++++++++++++++++++++++++++++++++-------------------------------- 1 files changed, 40 insertions(+), 40 deletions(-) -- 1.7.2.3 From thomas at xteddy.org Fri Jan 7 22:25:46 2011 From: thomas at xteddy.org (Thomas Adam) Date: Fri, 7 Jan 2011 22:25:46 +0000 Subject: [Vimprobable-users] [PATCH 1/3] Change all GObject cats to G_OBJECT Message-ID: <20110107222541.GA7652@debian> Don't explicitly cast a pointer to GObject* explicitly, instead use the G_OBJECT macro to help type-safety. --- main.c | 34 +++++++++++++++++----------------- 1 files changed, 17 insertions(+), 17 deletions(-) diff --git a/main.c b/main.c index 95ad0cd..ea7ca9a 100644 --- a/main.c +++ b/main.c @@ -1719,11 +1719,11 @@ process_set_line(char *line) { if (strlen(browsersettings[i].webkit) > 0) { /* activate appropriate webkit setting */ if (browsersettings[i].boolval) { - g_object_set((GObject*)settings, browsersettings[i].webkit, boolval, NULL); + g_object_set(G_OBJECT(settings), browsersettings[i].webkit, boolval, NULL); } else if (browsersettings[i].intval) { - g_object_set((GObject*)settings, browsersettings[i].webkit, atoi(my_pair.value), NULL); + g_object_set(G_OBJECT(settings), browsersettings[i].webkit, atoi(my_pair.value), NULL); } else { - g_object_set((GObject*)settings, browsersettings[i].webkit, my_pair.value, NULL); + g_object_set(G_OBJECT(settings), browsersettings[i].webkit, my_pair.value, NULL); } webkit_web_view_set_settings(webview, settings); } @@ -2068,15 +2068,15 @@ setup_settings() { int len; session = webkit_get_default_session(); - g_object_set((GObject*)settings, "default-font-size", DEFAULT_FONT_SIZE, NULL); - g_object_set((GObject*)settings, "enable-scripts", enablePlugins, NULL); - g_object_set((GObject*)settings, "enable-plugins", enablePlugins, NULL); - g_object_set((GObject*)settings, "enable-java-applet", enableJava, NULL); + g_object_set(G_OBJECT(settings), "default-font-size", DEFAULT_FONT_SIZE, NULL); + g_object_set(G_OBJECT(settings), "enable-scripts", enablePlugins, NULL); + g_object_set(G_OBJECT(settings), "enable-plugins", enablePlugins, NULL); + g_object_set(G_OBJECT(settings), "enable-java-applet", enableJava, NULL); filename = g_strdup_printf(USER_STYLESHEET); filename = g_strdup_printf("file://%s", filename); - g_object_set((GObject*)settings, "user-stylesheet-uri", filename, NULL); - g_object_set((GObject*)settings, "user-agent", useragent, NULL); - g_object_get((GObject*)settings, "zoom-step", &zoomstep, NULL); + g_object_set(G_OBJECT(settings), "user-stylesheet-uri", filename, NULL); + g_object_set(G_OBJECT(settings), "user-agent", useragent, NULL); + g_object_get(G_OBJECT(settings), "zoom-step", &zoomstep, NULL); webkit_web_view_set_settings(webview, settings); /* proxy */ @@ -2101,14 +2101,14 @@ void setup_signals() { #ifdef ENABLE_COOKIE_SUPPORT /* Headers. */ - g_signal_connect_after((GObject*)session, "request-started", (GCallback)new_generic_request, NULL); + g_signal_connect_after(G_OBJECT(session), "request-started", (GCallback)new_generic_request, NULL); #endif /* window */ - g_object_connect((GObject*)window, + g_object_connect(G_OBJECT(window), "signal::destroy", (GCallback)window_destroyed_cb, NULL, NULL); /* webview */ - g_object_connect((GObject*)webview, + g_object_connect(G_OBJECT(webview), "signal::title-changed", (GCallback)webview_title_changed_cb, NULL, "signal::load-progress-changed", (GCallback)webview_progress_changed_cb, NULL, "signal::load-committed", (GCallback)webview_load_committed_cb, NULL, @@ -2124,11 +2124,11 @@ setup_signals() { "signal::event", (GCallback)notify_event_cb, NULL, NULL); /* webview adjustment */ - g_object_connect((GObject*)adjust_v, + g_object_connect(G_OBJECT(adjust_v), "signal::value-changed", (GCallback)webview_scroll_cb, NULL, NULL); /* inputbox */ - g_object_connect((GObject*)inputbox, + g_object_connect(G_OBJECT(inputbox), "signal::activate", (GCallback)inputbox_activate_cb, NULL, "signal::key-press-event", (GCallback)inputbox_keypress_cb, NULL, "signal::key-release-event", (GCallback)inputbox_keyrelease_cb, NULL, @@ -2137,7 +2137,7 @@ setup_signals() { #endif NULL); /* inspector */ - g_signal_connect((GObject*)inspector, + g_signal_connect(G_OBJECT(inspector), "inspect-web-view", (GCallback)inspector_inspect_web_view_cb, NULL); } @@ -2157,7 +2157,7 @@ setup_cookies() load_all_cookies(); - g_signal_connect((GObject *)file_cookie_jar, "changed", + g_signal_connect(G_OBJECT(file_cookie_jar), "changed", G_CALLBACK(update_cookie_jar), NULL); return; -- 1.7.2.3 From thomas at xteddy.org Fri Jan 7 22:26:17 2011 From: thomas at xteddy.org (Thomas Adam) Date: Fri, 7 Jan 2011 22:26:17 +0000 Subject: [Vimprobable-users] [PATCH 2/3] Avoid GCallback* casts and use G_CALLBACK macro Message-ID: <20110107222613.GA7663@debian> Don't explicitly case pointers to GCallback*, instead use G_CALLBACK macro to help with type-safety. --- main.c | 42 +++++++++++++++++++++--------------------- 1 files changed, 21 insertions(+), 21 deletions(-) diff --git a/main.c b/main.c index ea7ca9a..73b2fb4 100644 --- a/main.c +++ b/main.c @@ -2101,44 +2101,44 @@ void setup_signals() { #ifdef ENABLE_COOKIE_SUPPORT /* Headers. */ - g_signal_connect_after(G_OBJECT(session), "request-started", (GCallback)new_generic_request, NULL); + g_signal_connect_after(G_OBJECT(session), "request-started", G_CALLBACK(new_generic_request), NULL); #endif /* window */ g_object_connect(G_OBJECT(window), - "signal::destroy", (GCallback)window_destroyed_cb, NULL, + "signal::destroy", G_CALLBACK(window_destroyed_cb), NULL, NULL); /* webview */ g_object_connect(G_OBJECT(webview), - "signal::title-changed", (GCallback)webview_title_changed_cb, NULL, - "signal::load-progress-changed", (GCallback)webview_progress_changed_cb, NULL, - "signal::load-committed", (GCallback)webview_load_committed_cb, NULL, - "signal::load-finished", (GCallback)webview_load_finished_cb, NULL, - "signal::navigation-policy-decision-requested", (GCallback)webview_navigation_cb, NULL, - "signal::new-window-policy-decision-requested", (GCallback)webview_new_window_cb, NULL, - "signal::mime-type-policy-decision-requested", (GCallback)webview_mimetype_cb, NULL, - "signal::download-requested", (GCallback)webview_download_cb, NULL, - "signal::key-press-event", (GCallback)webview_keypress_cb, NULL, - "signal::hovering-over-link", (GCallback)webview_hoverlink_cb, NULL, - "signal::console-message", (GCallback)webview_console_cb, NULL, - "signal::create-web-view", (GCallback)webview_open_in_new_window_cb, NULL, - "signal::event", (GCallback)notify_event_cb, NULL, + "signal::title-changed", G_CALLBACK(webview_title_changed_cb), NULL, + "signal::load-progress-changed", G_CALLBACK(webview_progress_changed_cb), NULL, + "signal::load-committed", G_CALLBACK(webview_load_committed_cb), NULL, + "signal::load-finished", G_CALLBACK(webview_load_finished_cb), NULL, + "signal::navigation-policy-decision-requested", G_CALLBACK(webview_navigation_cb), NULL, + "signal::new-window-policy-decision-requested", G_CALLBACK(webview_new_window_cb), NULL, + "signal::mime-type-policy-decision-requested", G_CALLBACK(webview_mimetype_cb), NULL, + "signal::download-requested", G_CALLBACK(webview_download_cb), NULL, + "signal::key-press-event", G_CALLBACK(webview_keypress_cb), NULL, + "signal::hovering-over-link", G_CALLBACK(webview_hoverlink_cb), NULL, + "signal::console-message", G_CALLBACK(webview_console_cb), NULL, + "signal::create-web-view", G_CALLBACK(webview_open_in_new_window_cb), NULL, + "signal::event", G_CALLBACK(notify_event_cb), NULL, NULL); /* webview adjustment */ g_object_connect(G_OBJECT(adjust_v), - "signal::value-changed", (GCallback)webview_scroll_cb, NULL, + "signal::value-changed", G_CALLBACK(webview_scroll_cb), NULL, NULL); /* inputbox */ g_object_connect(G_OBJECT(inputbox), - "signal::activate", (GCallback)inputbox_activate_cb, NULL, - "signal::key-press-event", (GCallback)inputbox_keypress_cb, NULL, - "signal::key-release-event", (GCallback)inputbox_keyrelease_cb, NULL, + "signal::activate", G_CALLBACK(inputbox_activate_cb), NULL, + "signal::key-press-event", G_CALLBACK(inputbox_keypress_cb), NULL, + "signal::key-release-event", G_CALLBACK(inputbox_keyrelease_cb), NULL, #ifdef ENABLE_INCREMENTAL_SEARCH - "signal::changed", (GCallback)inputbox_changed_cb, NULL, + "signal::changed", G_CALLBACK(inputbox_changed_cb), NULL, #endif NULL); /* inspector */ g_signal_connect(G_OBJECT(inspector), - "inspect-web-view", (GCallback)inspector_inspect_web_view_cb, NULL); + "inspect-web-view", G_CALLBACK(inspector_inspect_web_view_cb), NULL); } #ifdef ENABLE_COOKIE_SUPPORT -- 1.7.2.3 From thomas at xteddy.org Fri Jan 7 22:26:52 2011 From: thomas at xteddy.org (Thomas Adam) Date: Fri, 7 Jan 2011 22:26:52 +0000 Subject: [Vimprobable-users] [PATCH 3/3] Cast other misc GtkFoo* pointers to macros Message-ID: <20110107222648.GA7674@debian> In the interests of type-safety, convert other stray GtkFoo* pointers to their macro equivalents. --- main.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/main.c b/main.c index 73b2fb4..7e9cbcc 100644 --- a/main.c +++ b/main.c @@ -1895,7 +1895,7 @@ update_url(const char *uri) { if (!back && !fwd) before[0] = after[0] = '\0'; #endif - gtk_label_set_markup((GtkLabel*)status_url, g_markup_printf_escaped( + gtk_label_set_markup(GTK_LABEL(status_url), g_markup_printf_escaped( #ifdef ENABLE_HISTORY_INDICATOR "%s%s%s%s%s", statusfont, uri, before, back ? "+" : "", fwd ? "-" : "", after @@ -2000,9 +2000,9 @@ setup_gui() { adjust_h = gtk_range_get_adjustment(GTK_RANGE(scroll_h)); adjust_v = gtk_range_get_adjustment(GTK_RANGE(scroll_v)); if (embed) { - window = (GtkWindow *)gtk_plug_new(embed); + window = GTK_WINDOW(gtk_plug_new(embed)); } else { - window = (GtkWindow *)gtk_window_new(GTK_WINDOW_TOPLEVEL); + window = GTK_WINDOW(gtk_window_new(GTK_WINDOW_TOPLEVEL)); gtk_window_set_wmclass(GTK_WINDOW(window), "vimprobable2", "Vimprobable2"); } gtk_window_set_default_size(GTK_WINDOW(window), 640, 480); -- 1.7.2.3 From alkim1234 at gmail.com Tue Jan 11 07:08:20 2011 From: alkim1234 at gmail.com (alkim1234 at gmail.com) Date: Mon, 10 Jan 2011 23:08:20 -0800 Subject: [Vimprobable-users] ctrl-o, ctrl-i Message-ID: <20110111070820.GA15180@elements.hsd1.ca.comcast.net> Hi, I just wanted to point out that in the default config.h/keymap.h: goes forward goes backward which is opposite of what typical vim users expect. Thanks. From alkim1234 at gmail.com Tue Jan 11 09:26:33 2011 From: alkim1234 at gmail.com (alkim1234 at gmail.com) Date: Tue, 11 Jan 2011 01:26:33 -0800 Subject: [Vimprobable-users] Small Escape Patch Message-ID: <20110111092633.GA20305@elements.hsd1.ca.comcast.net> This is a small patch provides the macro IS_ESCAPE to check whether a GdkEventKey should be considered as an escape event. This patch also adds as an escape event. -------------- next part -------------- diff --git a/keymap.h b/keymap.h index b72e24d..51e0145 100644 --- a/keymap.h +++ b/keymap.h @@ -99,6 +99,7 @@ Key keys[] = { { GDK_SHIFT_MASK, 0, GDK_question, input, {.s = "?"} }, { 0, GDK_VoidSymbol, GDK_Escape, set, {ModeNormal} }, + { GDK_CONTROL_MASK, GDK_VoidSymbol, GDK_bracketleft,set, {ModeNormal} }, { GDK_CONTROL_MASK, 0, GDK_z, set, {ModePassThrough} }, { GDK_CONTROL_MASK, 0, GDK_v, set, {ModeSendKey} }, { 0, 0, GDK_f, set, { .i = ModeHints, .s = "current" } }, diff --git a/main.c b/main.c index 95ad0cd..9d63ff4 100644 --- a/main.c +++ b/main.c @@ -22,6 +22,9 @@ /* remove unused bits, numlock symbol and buttons from keymask */ #define CLEAN(mask) (mask & (GDK_MODIFIER_MASK) & ~(CLEAN_MOD_NUMLOCK_MASK) & ~(CLEAN_MOD_BUTTON_MASK)) +#define IS_ESCAPE(event) ((CLEAN(event->state) == 0 && event->keyval == GDK_Escape) ||\ + (CLEAN(event->state) == GDK_CONTROL_MASK && event->keyval == GDK_bracketleft)) + /* callbacks here */ static void inputbox_activate_cb(GtkEntry *entry, gpointer user_data); static gboolean inputbox_keypress_cb(GtkEntry *entry, GdkEventKey *event); @@ -342,7 +345,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { case ModeNormal: if (CLEAN(event->state) == 0) { memset(inputBuffer, 0, 65); - if (event->keyval == GDK_Escape) { + if (IS_ESCAPE(event)) { a.i = Info; a.s = g_strdup(""); echo(&a); @@ -362,7 +365,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { break; case ModeInsert: - if (CLEAN(event->state) == 0 && event->keyval == GDK_Escape) { + if (IS_ESCAPE(event)) { a.i = Silent; a.s = "vimprobable_clearfocus()"; script(&a); @@ -370,7 +373,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { return set(&a); } case ModePassThrough: - if (CLEAN(event->state) == 0 && event->keyval == GDK_Escape) { + if (IS_ESCAPE(event)) { echo(&a); set(&a); return TRUE; @@ -381,7 +384,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { set(&a); break; case ModeHints: - if (CLEAN(event->state) == 0 && event->keyval == GDK_Escape) { + if (IS_ESCAPE(event)) { a.i = Silent; a.s = "vimprobable_clear()"; script(&a); @@ -628,7 +631,9 @@ inputbox_keypress_cb(GtkEntry *entry, GdkEventKey *event) { Arg a; switch (event->keyval) { + case GDK_bracketleft: case GDK_Escape: + if (!IS_ESCAPE(event)) break; a.i = HideCompletion; complete(&a); a.i = ModeNormal; From thomas at xteddy.org Tue Jan 11 09:40:35 2011 From: thomas at xteddy.org (Thomas Adam) Date: Tue, 11 Jan 2011 09:40:35 +0000 Subject: [Vimprobable-users] Small Escape Patch In-Reply-To: <20110111092633.GA20305@elements.hsd1.ca.comcast.net> References: <20110111092633.GA20305@elements.hsd1.ca.comcast.net> Message-ID: <20110111094033.GA2918@abacus.soton.smoothwall.net> Hellom On Tue, Jan 11, 2011 at 01:26:33AM -0800, alkim1234 at gmail.com wrote: > This is a small patch provides the macro IS_ESCAPE to check whether a > GdkEventKey should be considered as an escape event. This patch also adds > as an escape event. > diff --git a/keymap.h b/keymap.h > index b72e24d..51e0145 100644 > --- a/keymap.h > +++ b/keymap.h > @@ -99,6 +99,7 @@ Key keys[] = { > { GDK_SHIFT_MASK, 0, GDK_question, input, {.s = "?"} }, > > { 0, GDK_VoidSymbol, GDK_Escape, set, {ModeNormal} }, > + { GDK_CONTROL_MASK, GDK_VoidSymbol, GDK_bracketleft,set, {ModeNormal} }, Ideally, this should be a separate patch. > { GDK_CONTROL_MASK, 0, GDK_z, set, {ModePassThrough} }, > { GDK_CONTROL_MASK, 0, GDK_v, set, {ModeSendKey} }, > { 0, 0, GDK_f, set, { .i = ModeHints, .s = "current" } }, > diff --git a/main.c b/main.c > index 95ad0cd..9d63ff4 100644 > --- a/main.c > +++ b/main.c > @@ -22,6 +22,9 @@ > /* remove unused bits, numlock symbol and buttons from keymask */ > #define CLEAN(mask) (mask & (GDK_MODIFIER_MASK) & ~(CLEAN_MOD_NUMLOCK_MASK) & ~(CLEAN_MOD_BUTTON_MASK)) > > +#define IS_ESCAPE(event) ((CLEAN(event->state) == 0 && event->keyval == GDK_Escape) ||\ > + (CLEAN(event->state) == GDK_CONTROL_MASK && event->keyval == GDK_bracketleft)) > + If we ever expand events like this -- to make other key combinations like this send an escape event, this macro will get ugly. Perhaps we should do something like the following? #define IS_ESCAPE(event) ((CLEAN(event->state) == 0 && IS_ESCAPE_KEY(s,k))) #define IS_ESCAPE_KEY(event) ((CLEAN(event->state) == GDK_CONTROL_MASK \ && event->keyval == GDK_bracketleft) || \ event->keyval == GDK_Escape) Although macros like this become terrible over time, and I think in the future we should move to inline functions with key tables in the proper sense. Otherwise this looks OK. -- Thomas Adam From alkim1234 at gmail.com Tue Jan 11 10:01:06 2011 From: alkim1234 at gmail.com (alkim1234 at gmail.com) Date: Tue, 11 Jan 2011 02:01:06 -0800 Subject: [Vimprobable-users] Small Escape Patch In-Reply-To: <20110111094033.GA2918@abacus.soton.smoothwall.net> References: <20110111092633.GA20305@elements.hsd1.ca.comcast.net> <20110111094033.GA2918@abacus.soton.smoothwall.net> Message-ID: <20110111100106.GA21019@elements.hsd1.ca.comcast.net> > Ideally, this should be a separate patch. Thanks, I'll keep this in mind. > If we ever expand events like this -- to make other key combinations like > this send an escape event, this macro will get ugly. Perhaps we should do > something like the following? > > #define IS_ESCAPE(event) ((CLEAN(event->state) == 0 && IS_ESCAPE_KEY(s,k))) > #define IS_ESCAPE_KEY(event) ((CLEAN(event->state) == GDK_CONTROL_MASK \ > && event->keyval == GDK_bracketleft) || \ > event->keyval == GDK_Escape) I assume you meant something like this: #define IS_ESCAPE(event) (IS_ESCAPE_KEY(CLEAN(event->state), event->keyval)) #define IS_ESCAPE_KEY(s,k) ((s == GDK_CONTROL_MASK && k == GDK_bracketleft) || \ ((s == 0) && (k == GDK_Escape))) Good idea. > Although macros like this become terrible over time, and I think in the > future we should move to inline functions with key tables in the proper > sense. Agreed. > Otherwise this looks OK. Great. I attached an updated patch incorporating your suggestion to the macro. -------------- next part -------------- diff --git a/keymap.h b/keymap.h index b72e24d..51e0145 100644 --- a/keymap.h +++ b/keymap.h @@ -99,6 +99,7 @@ Key keys[] = { { GDK_SHIFT_MASK, 0, GDK_question, input, {.s = "?"} }, { 0, GDK_VoidSymbol, GDK_Escape, set, {ModeNormal} }, + { GDK_CONTROL_MASK, GDK_VoidSymbol, GDK_bracketleft,set, {ModeNormal} }, { GDK_CONTROL_MASK, 0, GDK_z, set, {ModePassThrough} }, { GDK_CONTROL_MASK, 0, GDK_v, set, {ModeSendKey} }, { 0, 0, GDK_f, set, { .i = ModeHints, .s = "current" } }, diff --git a/main.c b/main.c index 95ad0cd..3a01348 100644 --- a/main.c +++ b/main.c @@ -22,6 +22,10 @@ /* remove unused bits, numlock symbol and buttons from keymask */ #define CLEAN(mask) (mask & (GDK_MODIFIER_MASK) & ~(CLEAN_MOD_NUMLOCK_MASK) & ~(CLEAN_MOD_BUTTON_MASK)) +#define IS_ESCAPE(event) (IS_ESCAPE_KEY(CLEAN(event->state), event->keyval)) +#define IS_ESCAPE_KEY(s, k) ((s == 0 && k == GDK_Escape) || \ + (s == GDK_CONTROL_MASK && k == GDK_bracketleft)) + /* callbacks here */ static void inputbox_activate_cb(GtkEntry *entry, gpointer user_data); static gboolean inputbox_keypress_cb(GtkEntry *entry, GdkEventKey *event); @@ -342,7 +346,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { case ModeNormal: if (CLEAN(event->state) == 0) { memset(inputBuffer, 0, 65); - if (event->keyval == GDK_Escape) { + if (IS_ESCAPE(event)) { a.i = Info; a.s = g_strdup(""); echo(&a); @@ -362,7 +366,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { break; case ModeInsert: - if (CLEAN(event->state) == 0 && event->keyval == GDK_Escape) { + if (IS_ESCAPE(event)) { a.i = Silent; a.s = "vimprobable_clearfocus()"; script(&a); @@ -370,7 +374,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { return set(&a); } case ModePassThrough: - if (CLEAN(event->state) == 0 && event->keyval == GDK_Escape) { + if (IS_ESCAPE(event)) { echo(&a); set(&a); return TRUE; @@ -381,7 +385,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { set(&a); break; case ModeHints: - if (CLEAN(event->state) == 0 && event->keyval == GDK_Escape) { + if (IS_ESCAPE(event)) { a.i = Silent; a.s = "vimprobable_clear()"; script(&a); @@ -628,7 +632,9 @@ inputbox_keypress_cb(GtkEntry *entry, GdkEventKey *event) { Arg a; switch (event->keyval) { + case GDK_bracketleft: case GDK_Escape: + if (!IS_ESCAPE(event)) break; a.i = HideCompletion; complete(&a); a.i = ModeNormal; From alkim1234 at gmail.com Fri Jan 14 09:03:32 2011 From: alkim1234 at gmail.com (Albert Kim) Date: Fri, 14 Jan 2011 01:03:32 -0800 Subject: [Vimprobable-users] [PATCH 0/8] New Way to Handle Hinting Message-ID: <1294995820-12957-1-git-send-email-alkim1234@gmail.com> I changed the hinting system so that it uses the inputbox instead of by keeping track of each new keypress. There are two primary advantages to this: 1. The code becomes a lot simpler because GtkEntry takes care of the whole unicode bit, and all we have to do is take care of updating the hints. 2. This allows for people to use their IMs to follow hints. Albert Kim (8): Added backquote as a synonym to start following hints. Uses inputbox_keypress_cb to find hints. Specified "current" for following hints. Make hints go away if input is cleared. Pressing ~ now sets up so that hints open up in background. Added proper handling of numbers into new hinting system. Changed 'f' and 'F' keys to use new hinting mode. Changed to reset count when quitting hintmode. keymap.h | 7 +++++-- main.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 54 insertions(+), 2 deletions(-) -- 1.7.3.5 From alkim1234 at gmail.com Fri Jan 14 09:03:33 2011 From: alkim1234 at gmail.com (Albert Kim) Date: Fri, 14 Jan 2011 01:03:33 -0800 Subject: [Vimprobable-users] [PATCH 1/8] Added backquote as a synonym to start following hints. In-Reply-To: <1294995820-12957-1-git-send-email-alkim1234@gmail.com> References: <1294995820-12957-1-git-send-email-alkim1234@gmail.com> Message-ID: <1294995820-12957-2-git-send-email-alkim1234@gmail.com> --- keymap.h | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/keymap.h b/keymap.h index b72e24d..c1b0b0d 100644 --- a/keymap.h +++ b/keymap.h @@ -98,6 +98,8 @@ Key keys[] = { { GDK_SHIFT_MASK, 0, GDK_slash, input, {.s = "/"} }, { GDK_SHIFT_MASK, 0, GDK_question, input, {.s = "?"} }, + { 0, 0, GDK_quoteleft, input, {.s = "`"} }, + { 0, GDK_VoidSymbol, GDK_Escape, set, {ModeNormal} }, { GDK_CONTROL_MASK, 0, GDK_z, set, {ModePassThrough} }, { GDK_CONTROL_MASK, 0, GDK_v, set, {ModeSendKey} }, -- 1.7.3.5 From alkim1234 at gmail.com Fri Jan 14 09:03:34 2011 From: alkim1234 at gmail.com (Albert Kim) Date: Fri, 14 Jan 2011 01:03:34 -0800 Subject: [Vimprobable-users] [PATCH 2/8] Uses inputbox_keypress_cb to find hints. In-Reply-To: <1294995820-12957-1-git-send-email-alkim1234@gmail.com> References: <1294995820-12957-1-git-send-email-alkim1234@gmail.com> Message-ID: <1294995820-12957-3-git-send-email-alkim1234@gmail.com> When, '`' is the first character of the inputbox, vimiprobable now uses the inputbox to find hints. This allows for a cleaner way to handle international characters and also allows for users to use their IM to type international characters. --- main.c | 12 ++++++++++++ 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/main.c b/main.c index 95ad0cd..2a1b1aa 100644 --- a/main.c +++ b/main.c @@ -691,6 +691,7 @@ static gboolean inputbox_keyrelease_cb(GtkEntry *entry, GdkEventKey *event) { } static gboolean inputbox_changed_cb(GtkEditable *entry, gpointer user_data) { + Arg a; char *text = (char*)gtk_entry_get_text(GTK_ENTRY(entry)); guint16 length = gtk_entry_get_text_length(GTK_ENTRY(entry)); gboolean forward = FALSE; @@ -707,6 +708,17 @@ static gboolean inputbox_changed_cb(GtkEditable *entry, gpointer user_data) { webkit_web_view_unmark_text_matches(webview); webkit_web_view_search_text(webview, &text[1], searchoptions & CaseSensitive, forward, searchoptions & Wrapping); return TRUE; + } else if (gtk_widget_is_focus(GTK_WIDGET(entry)) && length > 1 && + (text[0] == '`')) { + a.i = Silent; + a.s = "vimprobable_cleanup()"; + script(&a); + a.i = Silent; + a.s = g_strconcat("vimprobable_show_hints('", text + 1, "')", NULL); + script(&a); + free(a.s); + update_state(); + return TRUE; } return FALSE; -- 1.7.3.5 From alkim1234 at gmail.com Fri Jan 14 09:03:35 2011 From: alkim1234 at gmail.com (Albert Kim) Date: Fri, 14 Jan 2011 01:03:35 -0800 Subject: [Vimprobable-users] [PATCH 3/8] Specified "current" for following hints. In-Reply-To: <1294995820-12957-1-git-send-email-alkim1234@gmail.com> References: <1294995820-12957-1-git-send-email-alkim1234@gmail.com> Message-ID: <1294995820-12957-4-git-send-email-alkim1234@gmail.com> Also, made sure all hints are highlighted if nothing has been typed yet. --- main.c | 15 ++++++++++++++- 1 files changed, 14 insertions(+), 1 deletions(-) diff --git a/main.c b/main.c index 2a1b1aa..37c9ccb 100644 --- a/main.c +++ b/main.c @@ -708,15 +708,17 @@ static gboolean inputbox_changed_cb(GtkEditable *entry, gpointer user_data) { webkit_web_view_unmark_text_matches(webview); webkit_web_view_search_text(webview, &text[1], searchoptions & CaseSensitive, forward, searchoptions & Wrapping); return TRUE; - } else if (gtk_widget_is_focus(GTK_WIDGET(entry)) && length > 1 && + } else if (gtk_widget_is_focus(GTK_WIDGET(entry)) && length >= 1 && (text[0] == '`')) { a.i = Silent; a.s = "vimprobable_cleanup()"; script(&a); + a.i = Silent; a.s = g_strconcat("vimprobable_show_hints('", text + 1, "')", NULL); script(&a); free(a.s); + update_state(); return TRUE; } @@ -1000,6 +1002,7 @@ input(const Arg *arg) { count = 0; const char *url; int index = Info; + Arg a; update_state(); @@ -1016,6 +1019,16 @@ input(const Arg *arg) { gtk_editable_insert_text(GTK_EDITABLE(inputbox), url, -1, &pos); gtk_widget_grab_focus(inputbox); gtk_editable_set_position(GTK_EDITABLE(inputbox), -1); + + if (arg->s[0] == '`') { + memset(followTarget, 0, 0); + strncpy(followTarget, "current", 8); + a.i = Silent; + a.s = "vimprobable_show_hints()"; + script(&a); + update_state(); + } + return TRUE; } -- 1.7.3.5 From alkim1234 at gmail.com Fri Jan 14 09:03:36 2011 From: alkim1234 at gmail.com (Albert Kim) Date: Fri, 14 Jan 2011 01:03:36 -0800 Subject: [Vimprobable-users] [PATCH 4/8] Make hints go away if input is cleared. In-Reply-To: <1294995820-12957-1-git-send-email-alkim1234@gmail.com> References: <1294995820-12957-1-git-send-email-alkim1234@gmail.com> Message-ID: <1294995820-12957-5-git-send-email-alkim1234@gmail.com> Basically, now the existence of followTarget is what sets hint mode on or off. If followTarget is either ("current" or "new"), when inputbox's length becomes 0, vimprobable_clear is called. followTarget is set once the user sets inputbox to have '`' as the first character. --- main.c | 23 +++++++++++++---------- 1 files changed, 13 insertions(+), 10 deletions(-) diff --git a/main.c b/main.c index 37c9ccb..7d20661 100644 --- a/main.c +++ b/main.c @@ -719,8 +719,12 @@ static gboolean inputbox_changed_cb(GtkEditable *entry, gpointer user_data) { script(&a); free(a.s); - update_state(); return TRUE; + } else if (length == 0 && followTarget[0]) { + memset(followTarget, 0, 8); + a.i = Silent; + a.s = "vimprobable_clear()"; + script(&a); } return FALSE; @@ -1012,23 +1016,22 @@ input(const Arg *arg) { */ set_widget_font_and_color(inputbox, urlboxfont[index], urlboxbgcolor[index], urlboxcolor[index]); - /* to avoid things like :open URL :open URL2 or :open :open URL */ - gtk_entry_set_text(GTK_ENTRY(inputbox), ""); - gtk_editable_insert_text(GTK_EDITABLE(inputbox), arg->s, -1, &pos); - if (arg->i & InsertCurrentURL && (url = webkit_web_view_get_uri(webview))) - gtk_editable_insert_text(GTK_EDITABLE(inputbox), url, -1, &pos); - gtk_widget_grab_focus(inputbox); - gtk_editable_set_position(GTK_EDITABLE(inputbox), -1); - if (arg->s[0] == '`') { memset(followTarget, 0, 0); strncpy(followTarget, "current", 8); a.i = Silent; a.s = "vimprobable_show_hints()"; script(&a); - update_state(); } + /* to avoid things like :open URL :open URL2 or :open :open URL */ + gtk_entry_set_text(GTK_ENTRY(inputbox), ""); + gtk_editable_insert_text(GTK_EDITABLE(inputbox), arg->s, -1, &pos); + if (arg->i & InsertCurrentURL && (url = webkit_web_view_get_uri(webview))) + gtk_editable_insert_text(GTK_EDITABLE(inputbox), url, -1, &pos); + gtk_widget_grab_focus(inputbox); + gtk_editable_set_position(GTK_EDITABLE(inputbox), -1); + return TRUE; } -- 1.7.3.5 From alkim1234 at gmail.com Fri Jan 14 09:03:37 2011 From: alkim1234 at gmail.com (Albert Kim) Date: Fri, 14 Jan 2011 01:03:37 -0800 Subject: [Vimprobable-users] [PATCH 5/8] Pressing ~ now sets up so that hints open up in background. In-Reply-To: <1294995820-12957-1-git-send-email-alkim1234@gmail.com> References: <1294995820-12957-1-git-send-email-alkim1234@gmail.com> Message-ID: <1294995820-12957-6-git-send-email-alkim1234@gmail.com> --- keymap.h | 1 + main.c | 6 +++--- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/keymap.h b/keymap.h index c1b0b0d..f6f3237 100644 --- a/keymap.h +++ b/keymap.h @@ -99,6 +99,7 @@ Key keys[] = { { GDK_SHIFT_MASK, 0, GDK_question, input, {.s = "?"} }, { 0, 0, GDK_quoteleft, input, {.s = "`"} }, + { GDK_SHIFT_MASK, 0, GDK_asciitilde, input, {.s = "~"} }, { 0, GDK_VoidSymbol, GDK_Escape, set, {ModeNormal} }, { GDK_CONTROL_MASK, 0, GDK_z, set, {ModePassThrough} }, diff --git a/main.c b/main.c index 7d20661..7c0f34e 100644 --- a/main.c +++ b/main.c @@ -709,7 +709,7 @@ static gboolean inputbox_changed_cb(GtkEditable *entry, gpointer user_data) { webkit_web_view_search_text(webview, &text[1], searchoptions & CaseSensitive, forward, searchoptions & Wrapping); return TRUE; } else if (gtk_widget_is_focus(GTK_WIDGET(entry)) && length >= 1 && - (text[0] == '`')) { + (text[0] == '`' || text[0] == '~')) { a.i = Silent; a.s = "vimprobable_cleanup()"; script(&a); @@ -1016,9 +1016,9 @@ input(const Arg *arg) { */ set_widget_font_and_color(inputbox, urlboxfont[index], urlboxbgcolor[index], urlboxcolor[index]); - if (arg->s[0] == '`') { + if (arg->s[0] == '`' || arg->s[0] == '~') { memset(followTarget, 0, 0); - strncpy(followTarget, "current", 8); + strncpy(followTarget, arg->s[0] == '`' ? "current" : "new", 8); a.i = Silent; a.s = "vimprobable_show_hints()"; script(&a); -- 1.7.3.5 From alkim1234 at gmail.com Fri Jan 14 09:03:38 2011 From: alkim1234 at gmail.com (Albert Kim) Date: Fri, 14 Jan 2011 01:03:38 -0800 Subject: [Vimprobable-users] [PATCH 6/8] Added proper handling of numbers into new hinting system. In-Reply-To: <1294995820-12957-1-git-send-email-alkim1234@gmail.com> References: <1294995820-12957-1-git-send-email-alkim1234@gmail.com> Message-ID: <1294995820-12957-7-git-send-email-alkim1234@gmail.com> --- main.c | 19 +++++++++++++++++++ 1 files changed, 19 insertions(+), 0 deletions(-) diff --git a/main.c b/main.c index 7c0f34e..b1165a1 100644 --- a/main.c +++ b/main.c @@ -626,6 +626,7 @@ inputbox_activate_cb(GtkEntry *entry, gpointer user_data) { gboolean inputbox_keypress_cb(GtkEntry *entry, GdkEventKey *event) { Arg a; + char count_buf[BUFFERSIZE]; switch (event->keyval) { case GDK_Escape: @@ -651,6 +652,24 @@ inputbox_keypress_cb(GtkEntry *entry, GdkEventKey *event) { return complete(&a); break; } + + if (followTarget[0] && ((event->keyval >= GDK_1 && event->keyval <= GDK_9) + || (event->keyval >= GDK_KP_1 && event->keyval <= GDK_KP_9) + || ((event->keyval == GDK_0 || event->keyval == GDK_KP_0) && count))) { + /* allow a zero as non-first number */ + if (event->keyval >= GDK_KP_0 && event->keyval <= GDK_KP_9) + count = (count ? count * 10 : 0) + (event->keyval - GDK_KP_0); + else + count = (count ? count * 10 : 0) + (event->keyval - GDK_0); + snprintf(count_buf, BUFFERSIZE, "%d", count); + a.i = Silent; + a.s = g_strconcat("vimprobable_update_hints(", count_buf, ")", NULL); + script(&a); + update_state(); + g_free(a.s); + return TRUE; + } + return FALSE; } -- 1.7.3.5 From alkim1234 at gmail.com Fri Jan 14 09:03:39 2011 From: alkim1234 at gmail.com (Albert Kim) Date: Fri, 14 Jan 2011 01:03:39 -0800 Subject: [Vimprobable-users] [PATCH 7/8] Changed 'f' and 'F' keys to use new hinting mode. In-Reply-To: <1294995820-12957-1-git-send-email-alkim1234@gmail.com> References: <1294995820-12957-1-git-send-email-alkim1234@gmail.com> Message-ID: <1294995820-12957-8-git-send-email-alkim1234@gmail.com> --- keymap.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/keymap.h b/keymap.h index f6f3237..1ea3822 100644 --- a/keymap.h +++ b/keymap.h @@ -104,8 +104,8 @@ Key keys[] = { { 0, GDK_VoidSymbol, GDK_Escape, set, {ModeNormal} }, { GDK_CONTROL_MASK, 0, GDK_z, set, {ModePassThrough} }, { GDK_CONTROL_MASK, 0, GDK_v, set, {ModeSendKey} }, - { 0, 0, GDK_f, set, { .i = ModeHints, .s = "current" } }, - { GDK_SHIFT_MASK, 0, GDK_F, set, { .i = ModeHints, .s = "new" } }, + { 0, 0, GDK_f, input, {.s = "`"} }, + { GDK_SHIFT_MASK, 0, GDK_F, input, {.s = "~"} }, { 0, GDK_g, GDK_i, focus_input,{} }, { 0, 0, GDK_u, revive, {} }, -- 1.7.3.5 From alkim1234 at gmail.com Fri Jan 14 09:03:40 2011 From: alkim1234 at gmail.com (Albert Kim) Date: Fri, 14 Jan 2011 01:03:40 -0800 Subject: [Vimprobable-users] [PATCH 8/8] Changed to reset count when quitting hintmode. In-Reply-To: <1294995820-12957-1-git-send-email-alkim1234@gmail.com> References: <1294995820-12957-1-git-send-email-alkim1234@gmail.com> Message-ID: <1294995820-12957-9-git-send-email-alkim1234@gmail.com> Also calls update_state after count is reset. --- main.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/main.c b/main.c index b1165a1..1f9a7c5 100644 --- a/main.c +++ b/main.c @@ -744,6 +744,8 @@ static gboolean inputbox_changed_cb(GtkEditable *entry, gpointer user_data) { a.i = Silent; a.s = "vimprobable_clear()"; script(&a); + count = 0; + update_state(); } return FALSE; -- 1.7.3.5 From alkim1234 at gmail.com Fri Jan 14 09:09:29 2011 From: alkim1234 at gmail.com (alkim1234 at gmail.com) Date: Fri, 14 Jan 2011 01:09:29 -0800 Subject: [Vimprobable-users] [PATCH 0/8] New Way to Handle Hinting In-Reply-To: <1294995820-12957-1-git-send-email-alkim1234@gmail.com> References: <1294995820-12957-1-git-send-email-alkim1234@gmail.com> Message-ID: <20110114090929.GA13064@elements.hsd1.ca.comcast.net> There is one issue with this. Due to the way some IMs work (SCIM in particular), keypress events are not detected, and instead we may have to rely on keyrelease events to see which number was pressed. Right now, the implementation is with keypress events. On Fri, Jan 14, 2011 at 01:03:32AM -0800, Albert Kim wrote: > I changed the hinting system so that it uses the inputbox instead of by keeping > track of each new keypress. There are two primary advantages to this: > > 1. The code becomes a lot simpler because GtkEntry takes care of the whole > unicode bit, and all we have to do is take care of updating the hints. > > 2. This allows for people to use their IMs to follow hints. > > Albert Kim (8): > Added backquote as a synonym to start following hints. > Uses inputbox_keypress_cb to find hints. > Specified "current" for following hints. > Make hints go away if input is cleared. > Pressing ~ now sets up so that hints open up in background. > Added proper handling of numbers into new hinting system. > Changed 'f' and 'F' keys to use new hinting mode. > Changed to reset count when quitting hintmode. > > keymap.h | 7 +++++-- > main.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 54 insertions(+), 2 deletions(-) > > -- > 1.7.3.5 > From thomas at xteddy.org Fri Jan 14 09:49:36 2011 From: thomas at xteddy.org (Thomas Adam) Date: Fri, 14 Jan 2011 09:49:36 +0000 Subject: [Vimprobable-users] [PATCH 0/8] New Way to Handle Hinting In-Reply-To: <20110114090929.GA13064@elements.hsd1.ca.comcast.net> References: <1294995820-12957-1-git-send-email-alkim1234@gmail.com> <20110114090929.GA13064@elements.hsd1.ca.comcast.net> Message-ID: <20110114094933.GB6937@abacus.soton.smoothwall.net> On Fri, Jan 14, 2011 at 01:09:29AM -0800, alkim1234 at gmail.com wrote: > There is one issue with this. Due to the way some IMs work (SCIM in particular), > keypress events are not detected, and instead we may have to rely on keyrelease > events to see which number was pressed. Right now, the implementation is with > keypress events. Unfortunately, relying on keyrelease events is not guaranteed to work. -- Thomas Adam From thomas at xteddy.org Fri Jan 14 09:52:40 2011 From: thomas at xteddy.org (Thomas Adam) Date: Fri, 14 Jan 2011 09:52:40 +0000 Subject: [Vimprobable-users] [PATCH 2/8] Uses inputbox_keypress_cb to find hints. In-Reply-To: <1294995820-12957-3-git-send-email-alkim1234@gmail.com> References: <1294995820-12957-1-git-send-email-alkim1234@gmail.com> <1294995820-12957-3-git-send-email-alkim1234@gmail.com> Message-ID: <20110114095237.GC6937@abacus.soton.smoothwall.net> On Fri, Jan 14, 2011 at 01:03:34AM -0800, Albert Kim wrote: > When, '`' is the first character of the inputbox, vimiprobable now uses the > inputbox to find hints. This allows for a cleaner way to handle international > characters and also allows for users to use their IM to type international > characters. > --- > main.c | 12 ++++++++++++ > 1 files changed, 12 insertions(+), 0 deletions(-) > > diff --git a/main.c b/main.c > index 95ad0cd..2a1b1aa 100644 > --- a/main.c > +++ b/main.c > @@ -691,6 +691,7 @@ static gboolean inputbox_keyrelease_cb(GtkEntry *entry, GdkEventKey *event) { > } > > static gboolean inputbox_changed_cb(GtkEditable *entry, gpointer user_data) { > + Arg a; > char *text = (char*)gtk_entry_get_text(GTK_ENTRY(entry)); > guint16 length = gtk_entry_get_text_length(GTK_ENTRY(entry)); > gboolean forward = FALSE; > @@ -707,6 +708,17 @@ static gboolean inputbox_changed_cb(GtkEditable *entry, gpointer user_data) { > webkit_web_view_unmark_text_matches(webview); > webkit_web_view_search_text(webview, &text[1], searchoptions & CaseSensitive, forward, searchoptions & Wrapping); > return TRUE; > + } else if (gtk_widget_is_focus(GTK_WIDGET(entry)) && length > 1 && > + (text[0] == '`')) { > + a.i = Silent; > + a.s = "vimprobable_cleanup()"; > + script(&a); > + a.i = Silent; > + a.s = g_strconcat("vimprobable_show_hints('", text + 1, "')", NULL); > + script(&a); > + free(a.s); I don't like this -- as with 4815644f230434e49ebad393acc5ceac375a34a3, please just make script() free a.s where applicable. This comment applies to all other instances where you have this in your other patches. -- Thomas Adam From thomas at xteddy.org Fri Jan 14 09:57:19 2011 From: thomas at xteddy.org (Thomas Adam) Date: Fri, 14 Jan 2011 09:57:19 +0000 Subject: [Vimprobable-users] [PATCH 6/8] Added proper handling of numbers into new hinting system. In-Reply-To: <1294995820-12957-7-git-send-email-alkim1234@gmail.com> References: <1294995820-12957-1-git-send-email-alkim1234@gmail.com> <1294995820-12957-7-git-send-email-alkim1234@gmail.com> Message-ID: <20110114095717.GD6937@abacus.soton.smoothwall.net> On Fri, Jan 14, 2011 at 01:03:38AM -0800, Albert Kim wrote: > --- > main.c | 19 +++++++++++++++++++ > 1 files changed, 19 insertions(+), 0 deletions(-) > > diff --git a/main.c b/main.c > index 7c0f34e..b1165a1 100644 > --- a/main.c > +++ b/main.c > @@ -626,6 +626,7 @@ inputbox_activate_cb(GtkEntry *entry, gpointer user_data) { > gboolean > inputbox_keypress_cb(GtkEntry *entry, GdkEventKey *event) { > Arg a; > + char count_buf[BUFFERSIZE]; > > switch (event->keyval) { > case GDK_Escape: > @@ -651,6 +652,24 @@ inputbox_keypress_cb(GtkEntry *entry, GdkEventKey *event) { > return complete(&a); > break; > } > + > + if (followTarget[0] && ((event->keyval >= GDK_1 && event->keyval <= GDK_9) > + || (event->keyval >= GDK_KP_1 && event->keyval <= GDK_KP_9) > + || ((event->keyval == GDK_0 || event->keyval == GDK_KP_0) && count))) { You know what I'm going to tell you here, don't you? :) Remember our discussion regarding your escape() patch, and macro definitions? Please honour the ethos of that here. -- Thomas Adam From thomas at xteddy.org Fri Jan 14 10:00:02 2011 From: thomas at xteddy.org (Thomas Adam) Date: Fri, 14 Jan 2011 10:00:02 +0000 Subject: [Vimprobable-users] [PATCH 0/8] New Way to Handle Hinting In-Reply-To: <1294995820-12957-1-git-send-email-alkim1234@gmail.com> References: <1294995820-12957-1-git-send-email-alkim1234@gmail.com> Message-ID: <20110114100000.GE6937@abacus.soton.smoothwall.net> Hi, On Fri, Jan 14, 2011 at 01:03:32AM -0800, Albert Kim wrote: > I changed the hinting system so that it uses the inputbox instead of by keeping > track of each new keypress. There are two primary advantages to this: I don't care for this personally, but see comments regarding implementation for each patch where necessary. :) -- Thomas Adam From alkim1234 at gmail.com Fri Jan 14 10:43:13 2011 From: alkim1234 at gmail.com (alkim1234 at gmail.com) Date: Fri, 14 Jan 2011 02:43:13 -0800 Subject: [Vimprobable-users] [PATCH 0/8] New Way to Handle Hinting In-Reply-To: <20110114094933.GB6937@abacus.soton.smoothwall.net> References: <1294995820-12957-1-git-send-email-alkim1234@gmail.com> <20110114090929.GA13064@elements.hsd1.ca.comcast.net> <20110114094933.GB6937@abacus.soton.smoothwall.net> Message-ID: <20110114104312.GD13654@elements.hsd1.ca.comcast.net> > > There is one issue with this. Due to the way some IMs work (SCIM in particular), > > keypress events are not detected, and instead we may have to rely on keyrelease > > events to see which number was pressed. Right now, the implementation is with > > keypress events. > > Unfortunately, relying on keyrelease events is not guaranteed to work. Yes, but it's not quite as horrible as it seems. In my experience, when attempting to follow hint 33, I usually press a 3 and then another 3, rather than hold down 3 for a second and release. However, you're right that it is a hack... From alkim1234 at gmail.com Fri Jan 14 11:38:57 2011 From: alkim1234 at gmail.com (Albert Kim) Date: Fri, 14 Jan 2011 03:38:57 -0800 Subject: [Vimprobable-users] [PATCH 00/13] New Way to Handle Hinting Message-ID: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> I changed the hinting system so that it uses the inputbox instead of by keeping track of each new keypress. There are two primary advantages to this: 1. The code becomes a lot simpler because GtkEntry takes care of the whole unicode bit, and all we have to do is take care of updating the hints. 2. This allows for people to use their IMs to follow hints. EDIT: Updated for cleaner code. Albert Kim (13): Added backquote as a synonym to start following hints. Uses inputbox_keypress_cb to find hints. Specified "current" for following hints. Make hints go away if input is cleared. Pressing ~ now sets up so that hints open up in background. Added proper handling of numbers into new hinting system. Changed 'f' and 'F' keys to use new hinting mode. Changed to reset count when quitting hintmode. Made script() free arg->s where applicatable. Removed code dealing with old hintmode. Made check for whether keyval is digit shorter. Used numval instead of keyval to calculate new count. Fixed bug with not being able to press enter to follow single digit hints. keymap.h | 7 ++- main.c | 197 +++++++++++++++++-------------------------------------------- 2 files changed, 60 insertions(+), 144 deletions(-) -- 1.7.3.5 From alkim1234 at gmail.com Fri Jan 14 11:38:58 2011 From: alkim1234 at gmail.com (Albert Kim) Date: Fri, 14 Jan 2011 03:38:58 -0800 Subject: [Vimprobable-users] [PATCH 01/13] Added backquote as a synonym to start following hints. In-Reply-To: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> Message-ID: <1295005150-16318-2-git-send-email-alkim1234@gmail.com> --- keymap.h | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/keymap.h b/keymap.h index b72e24d..c1b0b0d 100644 --- a/keymap.h +++ b/keymap.h @@ -98,6 +98,8 @@ Key keys[] = { { GDK_SHIFT_MASK, 0, GDK_slash, input, {.s = "/"} }, { GDK_SHIFT_MASK, 0, GDK_question, input, {.s = "?"} }, + { 0, 0, GDK_quoteleft, input, {.s = "`"} }, + { 0, GDK_VoidSymbol, GDK_Escape, set, {ModeNormal} }, { GDK_CONTROL_MASK, 0, GDK_z, set, {ModePassThrough} }, { GDK_CONTROL_MASK, 0, GDK_v, set, {ModeSendKey} }, -- 1.7.3.5 From alkim1234 at gmail.com Fri Jan 14 11:38:59 2011 From: alkim1234 at gmail.com (Albert Kim) Date: Fri, 14 Jan 2011 03:38:59 -0800 Subject: [Vimprobable-users] [PATCH 02/13] Uses inputbox_keypress_cb to find hints. In-Reply-To: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> Message-ID: <1295005150-16318-3-git-send-email-alkim1234@gmail.com> When, '`' is the first character of the inputbox, vimiprobable now uses the inputbox to find hints. This allows for a cleaner way to handle international characters and also allows for users to use their IM to type international characters. --- main.c | 12 ++++++++++++ 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/main.c b/main.c index 95ad0cd..2a1b1aa 100644 --- a/main.c +++ b/main.c @@ -691,6 +691,7 @@ static gboolean inputbox_keyrelease_cb(GtkEntry *entry, GdkEventKey *event) { } static gboolean inputbox_changed_cb(GtkEditable *entry, gpointer user_data) { + Arg a; char *text = (char*)gtk_entry_get_text(GTK_ENTRY(entry)); guint16 length = gtk_entry_get_text_length(GTK_ENTRY(entry)); gboolean forward = FALSE; @@ -707,6 +708,17 @@ static gboolean inputbox_changed_cb(GtkEditable *entry, gpointer user_data) { webkit_web_view_unmark_text_matches(webview); webkit_web_view_search_text(webview, &text[1], searchoptions & CaseSensitive, forward, searchoptions & Wrapping); return TRUE; + } else if (gtk_widget_is_focus(GTK_WIDGET(entry)) && length > 1 && + (text[0] == '`')) { + a.i = Silent; + a.s = "vimprobable_cleanup()"; + script(&a); + a.i = Silent; + a.s = g_strconcat("vimprobable_show_hints('", text + 1, "')", NULL); + script(&a); + free(a.s); + update_state(); + return TRUE; } return FALSE; -- 1.7.3.5 From alkim1234 at gmail.com Fri Jan 14 11:39:00 2011 From: alkim1234 at gmail.com (Albert Kim) Date: Fri, 14 Jan 2011 03:39:00 -0800 Subject: [Vimprobable-users] [PATCH 03/13] Specified "current" for following hints. In-Reply-To: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> Message-ID: <1295005150-16318-4-git-send-email-alkim1234@gmail.com> Also, made sure all hints are highlighted if nothing has been typed yet. --- main.c | 15 ++++++++++++++- 1 files changed, 14 insertions(+), 1 deletions(-) diff --git a/main.c b/main.c index 2a1b1aa..37c9ccb 100644 --- a/main.c +++ b/main.c @@ -708,15 +708,17 @@ static gboolean inputbox_changed_cb(GtkEditable *entry, gpointer user_data) { webkit_web_view_unmark_text_matches(webview); webkit_web_view_search_text(webview, &text[1], searchoptions & CaseSensitive, forward, searchoptions & Wrapping); return TRUE; - } else if (gtk_widget_is_focus(GTK_WIDGET(entry)) && length > 1 && + } else if (gtk_widget_is_focus(GTK_WIDGET(entry)) && length >= 1 && (text[0] == '`')) { a.i = Silent; a.s = "vimprobable_cleanup()"; script(&a); + a.i = Silent; a.s = g_strconcat("vimprobable_show_hints('", text + 1, "')", NULL); script(&a); free(a.s); + update_state(); return TRUE; } @@ -1000,6 +1002,7 @@ input(const Arg *arg) { count = 0; const char *url; int index = Info; + Arg a; update_state(); @@ -1016,6 +1019,16 @@ input(const Arg *arg) { gtk_editable_insert_text(GTK_EDITABLE(inputbox), url, -1, &pos); gtk_widget_grab_focus(inputbox); gtk_editable_set_position(GTK_EDITABLE(inputbox), -1); + + if (arg->s[0] == '`') { + memset(followTarget, 0, 0); + strncpy(followTarget, "current", 8); + a.i = Silent; + a.s = "vimprobable_show_hints()"; + script(&a); + update_state(); + } + return TRUE; } -- 1.7.3.5 From alkim1234 at gmail.com Fri Jan 14 11:39:01 2011 From: alkim1234 at gmail.com (Albert Kim) Date: Fri, 14 Jan 2011 03:39:01 -0800 Subject: [Vimprobable-users] [PATCH 04/13] Make hints go away if input is cleared. In-Reply-To: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> Message-ID: <1295005150-16318-5-git-send-email-alkim1234@gmail.com> Basically, now the existence of followTarget is what sets hint mode on or off. If followTarget is either ("current" or "new"), when inputbox's length becomes 0, vimprobable_clear is called. followTarget is set once the user sets inputbox to have '`' as the first character. --- main.c | 23 +++++++++++++---------- 1 files changed, 13 insertions(+), 10 deletions(-) diff --git a/main.c b/main.c index 37c9ccb..7d20661 100644 --- a/main.c +++ b/main.c @@ -719,8 +719,12 @@ static gboolean inputbox_changed_cb(GtkEditable *entry, gpointer user_data) { script(&a); free(a.s); - update_state(); return TRUE; + } else if (length == 0 && followTarget[0]) { + memset(followTarget, 0, 8); + a.i = Silent; + a.s = "vimprobable_clear()"; + script(&a); } return FALSE; @@ -1012,23 +1016,22 @@ input(const Arg *arg) { */ set_widget_font_and_color(inputbox, urlboxfont[index], urlboxbgcolor[index], urlboxcolor[index]); - /* to avoid things like :open URL :open URL2 or :open :open URL */ - gtk_entry_set_text(GTK_ENTRY(inputbox), ""); - gtk_editable_insert_text(GTK_EDITABLE(inputbox), arg->s, -1, &pos); - if (arg->i & InsertCurrentURL && (url = webkit_web_view_get_uri(webview))) - gtk_editable_insert_text(GTK_EDITABLE(inputbox), url, -1, &pos); - gtk_widget_grab_focus(inputbox); - gtk_editable_set_position(GTK_EDITABLE(inputbox), -1); - if (arg->s[0] == '`') { memset(followTarget, 0, 0); strncpy(followTarget, "current", 8); a.i = Silent; a.s = "vimprobable_show_hints()"; script(&a); - update_state(); } + /* to avoid things like :open URL :open URL2 or :open :open URL */ + gtk_entry_set_text(GTK_ENTRY(inputbox), ""); + gtk_editable_insert_text(GTK_EDITABLE(inputbox), arg->s, -1, &pos); + if (arg->i & InsertCurrentURL && (url = webkit_web_view_get_uri(webview))) + gtk_editable_insert_text(GTK_EDITABLE(inputbox), url, -1, &pos); + gtk_widget_grab_focus(inputbox); + gtk_editable_set_position(GTK_EDITABLE(inputbox), -1); + return TRUE; } -- 1.7.3.5 From alkim1234 at gmail.com Fri Jan 14 11:39:02 2011 From: alkim1234 at gmail.com (Albert Kim) Date: Fri, 14 Jan 2011 03:39:02 -0800 Subject: [Vimprobable-users] [PATCH 05/13] Pressing ~ now sets up so that hints open up in background. In-Reply-To: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> Message-ID: <1295005150-16318-6-git-send-email-alkim1234@gmail.com> --- keymap.h | 1 + main.c | 6 +++--- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/keymap.h b/keymap.h index c1b0b0d..f6f3237 100644 --- a/keymap.h +++ b/keymap.h @@ -99,6 +99,7 @@ Key keys[] = { { GDK_SHIFT_MASK, 0, GDK_question, input, {.s = "?"} }, { 0, 0, GDK_quoteleft, input, {.s = "`"} }, + { GDK_SHIFT_MASK, 0, GDK_asciitilde, input, {.s = "~"} }, { 0, GDK_VoidSymbol, GDK_Escape, set, {ModeNormal} }, { GDK_CONTROL_MASK, 0, GDK_z, set, {ModePassThrough} }, diff --git a/main.c b/main.c index 7d20661..7c0f34e 100644 --- a/main.c +++ b/main.c @@ -709,7 +709,7 @@ static gboolean inputbox_changed_cb(GtkEditable *entry, gpointer user_data) { webkit_web_view_search_text(webview, &text[1], searchoptions & CaseSensitive, forward, searchoptions & Wrapping); return TRUE; } else if (gtk_widget_is_focus(GTK_WIDGET(entry)) && length >= 1 && - (text[0] == '`')) { + (text[0] == '`' || text[0] == '~')) { a.i = Silent; a.s = "vimprobable_cleanup()"; script(&a); @@ -1016,9 +1016,9 @@ input(const Arg *arg) { */ set_widget_font_and_color(inputbox, urlboxfont[index], urlboxbgcolor[index], urlboxcolor[index]); - if (arg->s[0] == '`') { + if (arg->s[0] == '`' || arg->s[0] == '~') { memset(followTarget, 0, 0); - strncpy(followTarget, "current", 8); + strncpy(followTarget, arg->s[0] == '`' ? "current" : "new", 8); a.i = Silent; a.s = "vimprobable_show_hints()"; script(&a); -- 1.7.3.5 From alkim1234 at gmail.com Fri Jan 14 11:39:03 2011 From: alkim1234 at gmail.com (Albert Kim) Date: Fri, 14 Jan 2011 03:39:03 -0800 Subject: [Vimprobable-users] [PATCH 06/13] Added proper handling of numbers into new hinting system. In-Reply-To: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> Message-ID: <1295005150-16318-7-git-send-email-alkim1234@gmail.com> --- main.c | 19 +++++++++++++++++++ 1 files changed, 19 insertions(+), 0 deletions(-) diff --git a/main.c b/main.c index 7c0f34e..b1165a1 100644 --- a/main.c +++ b/main.c @@ -626,6 +626,7 @@ inputbox_activate_cb(GtkEntry *entry, gpointer user_data) { gboolean inputbox_keypress_cb(GtkEntry *entry, GdkEventKey *event) { Arg a; + char count_buf[BUFFERSIZE]; switch (event->keyval) { case GDK_Escape: @@ -651,6 +652,24 @@ inputbox_keypress_cb(GtkEntry *entry, GdkEventKey *event) { return complete(&a); break; } + + if (followTarget[0] && ((event->keyval >= GDK_1 && event->keyval <= GDK_9) + || (event->keyval >= GDK_KP_1 && event->keyval <= GDK_KP_9) + || ((event->keyval == GDK_0 || event->keyval == GDK_KP_0) && count))) { + /* allow a zero as non-first number */ + if (event->keyval >= GDK_KP_0 && event->keyval <= GDK_KP_9) + count = (count ? count * 10 : 0) + (event->keyval - GDK_KP_0); + else + count = (count ? count * 10 : 0) + (event->keyval - GDK_0); + snprintf(count_buf, BUFFERSIZE, "%d", count); + a.i = Silent; + a.s = g_strconcat("vimprobable_update_hints(", count_buf, ")", NULL); + script(&a); + update_state(); + g_free(a.s); + return TRUE; + } + return FALSE; } -- 1.7.3.5 From alkim1234 at gmail.com Fri Jan 14 11:39:04 2011 From: alkim1234 at gmail.com (Albert Kim) Date: Fri, 14 Jan 2011 03:39:04 -0800 Subject: [Vimprobable-users] [PATCH 07/13] Changed 'f' and 'F' keys to use new hinting mode. In-Reply-To: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> Message-ID: <1295005150-16318-8-git-send-email-alkim1234@gmail.com> --- keymap.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/keymap.h b/keymap.h index f6f3237..1ea3822 100644 --- a/keymap.h +++ b/keymap.h @@ -104,8 +104,8 @@ Key keys[] = { { 0, GDK_VoidSymbol, GDK_Escape, set, {ModeNormal} }, { GDK_CONTROL_MASK, 0, GDK_z, set, {ModePassThrough} }, { GDK_CONTROL_MASK, 0, GDK_v, set, {ModeSendKey} }, - { 0, 0, GDK_f, set, { .i = ModeHints, .s = "current" } }, - { GDK_SHIFT_MASK, 0, GDK_F, set, { .i = ModeHints, .s = "new" } }, + { 0, 0, GDK_f, input, {.s = "`"} }, + { GDK_SHIFT_MASK, 0, GDK_F, input, {.s = "~"} }, { 0, GDK_g, GDK_i, focus_input,{} }, { 0, 0, GDK_u, revive, {} }, -- 1.7.3.5 From alkim1234 at gmail.com Fri Jan 14 11:39:05 2011 From: alkim1234 at gmail.com (Albert Kim) Date: Fri, 14 Jan 2011 03:39:05 -0800 Subject: [Vimprobable-users] [PATCH 08/13] Changed to reset count when quitting hintmode. In-Reply-To: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> Message-ID: <1295005150-16318-9-git-send-email-alkim1234@gmail.com> Also calls update_state after count is reset. --- main.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/main.c b/main.c index b1165a1..1f9a7c5 100644 --- a/main.c +++ b/main.c @@ -744,6 +744,8 @@ static gboolean inputbox_changed_cb(GtkEditable *entry, gpointer user_data) { a.i = Silent; a.s = "vimprobable_clear()"; script(&a); + count = 0; + update_state(); } return FALSE; -- 1.7.3.5 From alkim1234 at gmail.com Fri Jan 14 11:39:06 2011 From: alkim1234 at gmail.com (Albert Kim) Date: Fri, 14 Jan 2011 03:39:06 -0800 Subject: [Vimprobable-users] [PATCH 09/13] Made script() free arg->s where applicatable. In-Reply-To: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> Message-ID: <1295005150-16318-10-git-send-email-alkim1234@gmail.com> --- main.c | 16 ++++++++-------- 1 files changed, 8 insertions(+), 8 deletions(-) diff --git a/main.c b/main.c index 1f9a7c5..1e47891 100644 --- a/main.c +++ b/main.c @@ -193,7 +193,7 @@ ascii_bar(int total, int state, char *string) { void webview_load_committed_cb(WebKitWebView *webview, WebKitWebFrame *frame, gpointer user_data) { - Arg a = { .i = Silent, .s = JS_SETUP_HINTS }; + Arg a = { .i = Silent, .s = g_strdup(JS_SETUP_HINTS) }; const char *uri = webkit_web_view_get_uri(webview); update_url(uri); @@ -202,7 +202,7 @@ webview_load_committed_cb(WebKitWebView *webview, WebKitWebFrame *frame, gpointe void webview_load_finished_cb(WebKitWebView *webview, WebKitWebFrame *frame, gpointer user_data) { - Arg a = { .i = Silent, .s = JS_SETUP_INPUT_FOCUS }; + Arg a = { .i = Silent, .s = g_strdup(JS_SETUP_INPUT_FOCUS) }; if (HISTORY_MAX_ENTRIES > 0) history(); @@ -666,7 +666,6 @@ inputbox_keypress_cb(GtkEntry *entry, GdkEventKey *event) { a.s = g_strconcat("vimprobable_update_hints(", count_buf, ")", NULL); script(&a); update_state(); - g_free(a.s); return TRUE; } @@ -730,19 +729,18 @@ static gboolean inputbox_changed_cb(GtkEditable *entry, gpointer user_data) { } else if (gtk_widget_is_focus(GTK_WIDGET(entry)) && length >= 1 && (text[0] == '`' || text[0] == '~')) { a.i = Silent; - a.s = "vimprobable_cleanup()"; + a.s = g_strdup("vimprobable_cleanup()"); script(&a); a.i = Silent; a.s = g_strconcat("vimprobable_show_hints('", text + 1, "')", NULL); script(&a); - free(a.s); return TRUE; } else if (length == 0 && followTarget[0]) { memset(followTarget, 0, 8); a.i = Silent; - a.s = "vimprobable_clear()"; + a.s = g_strdup("vimprobable_clear()"); script(&a); count = 0; update_state(); @@ -1041,7 +1039,7 @@ input(const Arg *arg) { memset(followTarget, 0, 0); strncpy(followTarget, arg->s[0] == '`' ? "current" : "new", 8); a.i = Silent; - a.s = "vimprobable_show_hints()"; + a.s = g_strdup("vimprobable_show_hints()"); script(&a); } @@ -1313,7 +1311,7 @@ set(const Arg *arg) { memset(followTarget, 0, 8); strncpy(followTarget, arg->s, 8); a.i = Silent; - a.s = "vimprobable_show_hints()"; + a.s = g_strdup("vimprobable_show_hints()"); script(&a); break; default: @@ -1396,6 +1394,7 @@ script(const Arg *arg) { jsapi_evaluate_script(arg->s, &value, &message); if (message) { set_error(message); + if (arg->s) g_free(arg->s); return FALSE; } if (arg->i != Silent && value) { @@ -1426,6 +1425,7 @@ script(const Arg *arg) { open_arg(&a); } } + if (arg->s) g_free(arg->s); g_free(value); return TRUE; } -- 1.7.3.5 From alkim1234 at gmail.com Fri Jan 14 11:39:07 2011 From: alkim1234 at gmail.com (Albert Kim) Date: Fri, 14 Jan 2011 03:39:07 -0800 Subject: [Vimprobable-users] [PATCH 10/13] Removed code dealing with old hintmode. In-Reply-To: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> Message-ID: <1295005150-16318-11-git-send-email-alkim1234@gmail.com> --- main.c | 140 +--------------------------------------------------------------- 1 files changed, 1 insertions(+), 139 deletions(-) diff --git a/main.c b/main.c index 1e47891..e54985a 100644 --- a/main.c +++ b/main.c @@ -128,9 +128,6 @@ static char *configfile = NULL; static char *winid = NULL; static char rememberedURI[128] = ""; -static char inputKey[5]; -static char inputBuffer[65] = ""; -static char chars[65] = "0000000000000000000000000000000000000000000000000000000000000000\n"; static char followTarget[8] = ""; char *error_msg = NULL; @@ -341,7 +338,6 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { switch (mode) { case ModeNormal: if (CLEAN(event->state) == 0) { - memset(inputBuffer, 0, 65); if (event->keyval == GDK_Escape) { a.i = Info; a.s = g_strdup(""); @@ -380,127 +376,6 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { echo(&a); set(&a); break; - case ModeHints: - if (CLEAN(event->state) == 0 && event->keyval == GDK_Escape) { - a.i = Silent; - a.s = "vimprobable_clear()"; - script(&a); - a.i = ModeNormal; - count = 0; - strncpy(chars, "0000000000000000000000000000000000000000000000000000000000000000\0", 65); - return set(&a); - } else if (CLEAN(event->state) == 0 && ((event->keyval >= GDK_1 && event->keyval <= GDK_9) - || (event->keyval >= GDK_KP_1 && event->keyval <= GDK_KP_9) - || ((event->keyval == GDK_0 || event->keyval == GDK_KP_0) && count))) { - /* allow a zero as non-first number */ - if (event->keyval >= GDK_KP_0 && event->keyval <= GDK_KP_9) - count = (count ? count * 10 : 0) + (event->keyval - GDK_KP_0); - else - count = (count ? count * 10 : 0) + (event->keyval - GDK_0); - memset(inputBuffer, 0, 65); - sprintf(inputBuffer, "%d", count); - a.s = g_strconcat("vimprobable_update_hints(", inputBuffer, ")", NULL); - a.i = Silent; - memset(inputBuffer, 0, 65); - strncpy(chars, "0000000000000000000000000000000000000000000000000000000000000000\0", 65); - script(&a); - update_state(); - return TRUE; - } else if ((CLEAN(event->state) == 0 && (event->keyval >= GDK_a && event->keyval <= GDK_z)) - || (CLEAN(event->state) == GDK_SHIFT_MASK && (event->keyval >= GDK_A && event->keyval <= GDK_Z)) - || ((CLEAN(event->state) == 0 || CLEAN(event->state) == GDK_SHIFT_MASK) && (event->keyval >= GDK_space && event->keyval <= GDK_slash)) - || ((CLEAN(event->state) == 0 || CLEAN(event->state) == GDK_SHIFT_MASK) && (event->keyval >= GDK_colon && event->keyval <= GDK_at)) - || ((CLEAN(event->state) == 0 || CLEAN(event->state) == GDK_SHIFT_MASK) && (event->keyval >= GDK_braceleft && event->keyval <= GDK_umacron)) - || ((CLEAN(event->state) == 0 || CLEAN(event->state) == GDK_SHIFT_MASK) && (event->keyval >= GDK_Babovedot && event->keyval <= GDK_ycircumflex)) - || ((CLEAN(event->state) == 0 || CLEAN(event->state) == GDK_SHIFT_MASK) && (event->keyval >= GDK_OE && event->keyval <= GDK_Ydiaeresis)) - || ((CLEAN(event->state) == 0 || CLEAN(event->state) == GDK_SHIFT_MASK) && (event->keyval >= GDK_overline && event->keyval <= GDK_semivoicedsound)) - || ((CLEAN(event->state) == 0 || CLEAN(event->state) == GDK_SHIFT_MASK) && (event->keyval >= GDK_Farsi_0 && event->keyval <= GDK_Arabic_9)) - || ((CLEAN(event->state) == 0 || CLEAN(event->state) == GDK_SHIFT_MASK) && (event->keyval >= GDK_Arabic_semicolon && event->keyval <= GDK_Arabic_sukun)) - || ((CLEAN(event->state) == 0 || CLEAN(event->state) == GDK_SHIFT_MASK) && (event->keyval >= GDK_Arabic_madda_above && event->keyval <= GDK_Arabic_heh_goal)) - || ((CLEAN(event->state) == 0 || CLEAN(event->state) == GDK_SHIFT_MASK) && (event->keyval >= GDK_Cyrillic_GHE_bar && event->keyval <= GDK_Cyrillic_u_macron)) - || ((CLEAN(event->state) == 0 || CLEAN(event->state) == GDK_SHIFT_MASK) && (event->keyval >= GDK_Serbian_dje && event->keyval <= GDK_Korean_Won)) - || ((CLEAN(event->state) == 0 || CLEAN(event->state) == GDK_SHIFT_MASK) && (event->keyval >= GDK_Armenian_ligature_ew && event->keyval <= GDK_braille_dots_12345678))) { - /* update hints by link text */ - if (strlen(inputBuffer) < 65) { - memset(inputKey, 0, 5); - /* support multibyte characters */ - sprintf(inputKey, "%C", event->keyval); - strncat(inputBuffer, inputKey, 64 - strlen(inputBuffer)); - /* remember the number of bytes of each character */ - for (count = 0; count < 64; count++) { - if (strncmp((chars + count), "0", 1) == 0) { - sprintf(inputKey, "%d", (int)strlen(inputKey)); - strncpy((chars + count), inputKey, 1); - break; - } - } - memset(inputKey, 0, 5); - count = 0; - a.i = Silent; - a.s = "vimprobable_cleanup()"; - script(&a); - a.s = g_strconcat("vimprobable_show_hints('", inputBuffer, "')", NULL); - a.i = Silent; - script(&a); - update_state(); - } - return TRUE; - } else if (CLEAN(event->state) == 0 && (event->keyval == GDK_Return || event->keyval == GDK_KP_Enter) && count) { - memset(inputBuffer, 0, 65); - sprintf(inputBuffer, "%d", count); - a.s = g_strconcat("vimprobable_fire(", inputBuffer, ")", NULL); - a.i = Silent; - script(&a); - memset(inputBuffer, 0, 65); - count = 0; - strncpy(chars, "0000000000000000000000000000000000000000000000000000000000000000\0", 65); - update_state(); - return TRUE; - } else if (CLEAN(event->state) == 0 && event->keyval == GDK_BackSpace) { - if (count > 9) { - count /= 10; - memset(inputBuffer, 0, 65); - sprintf(inputBuffer, "%d", count); - a.s = g_strconcat("vimprobable_update_hints(", inputBuffer, ")", NULL); - a.i = Silent; - memset(inputBuffer, 0, 65); - script(&a); - update_state(); - } else if (count > 0) { - count = 0; - memset(inputBuffer, 0, 65); - a.i = Silent; - a.s = "vimprobable_cleanup()"; - script(&a); - a.s = g_strconcat("vimprobable_show_hints()", NULL); - a.i = Silent; - script(&a); - update_state(); - } else if (strlen(inputBuffer) > 0) { - a.i = Silent; - a.s = "vimprobable_cleanup()"; - script(&a); - /* check how many bytes the last character uses */ - for (count = 0; count < 64; count++) { - if (strncmp((chars + count), "0", 1) == 0) { - break; - } - } - memset(inputKey, 0, 5); - strncpy(inputKey, (chars + count - 1), 1); - strncpy((chars + count - 1), "0", 1); - count = atoi(inputKey); - /* remove the appropriate number of bytes from the string */ - strncpy((inputBuffer + strlen(inputBuffer) - count), "\0", 1); - count = 0; - a.s = g_strconcat("vimprobable_show_hints('", inputBuffer, "')", NULL); - a.i = Silent; - script(&a); - update_state(); - } - return TRUE; - } - break; } return FALSE; } @@ -661,9 +536,8 @@ inputbox_keypress_cb(GtkEntry *entry, GdkEventKey *event) { count = (count ? count * 10 : 0) + (event->keyval - GDK_KP_0); else count = (count ? count * 10 : 0) + (event->keyval - GDK_0); - snprintf(count_buf, BUFFERSIZE, "%d", count); a.i = Silent; - a.s = g_strconcat("vimprobable_update_hints(", count_buf, ")", NULL); + a.s = g_strdup_printf("vimprobable_update_hints(%d)", count); script(&a); update_state(); return TRUE; @@ -1307,13 +1181,6 @@ set(const Arg *arg) { a.s = g_strdup("-- INSERT --"); echo(&a); break; - case ModeHints: - memset(followTarget, 0, 8); - strncpy(followTarget, arg->s, 8); - a.i = Silent; - a.s = g_strdup("vimprobable_show_hints()"); - script(&a); - break; default: return TRUE; } @@ -1405,15 +1272,11 @@ script(const Arg *arg) { if (value) { if (strncmp(value, "fire;", 5) == 0) { count = 0; - strncpy(chars, "0000000000000000000000000000000000000000000000000000000000000000", 64); - memset(inputBuffer, 0, 65); a.s = g_strconcat("vimprobable_fire(", (value + 5), ")", NULL); a.i = Silent; script(&a); } else if (strncmp(value, "open;", 5) == 0) { count = 0; - strncpy(chars, "0000000000000000000000000000000000000000000000000000000000000000", 64); - memset(inputBuffer, 0, 65); a.i = ModeNormal; set(&a); if (strncmp(followTarget, "new", 3) == 0) @@ -1970,7 +1833,6 @@ update_state() { /* count, modkey and input buffer */ g_string_append_printf(status, "%.0d", count); if (current_modkey) g_string_append_c(status, current_modkey); - if (inputBuffer[0]) g_string_append_printf(status, " %s", inputBuffer); /* the number of active downloads */ if (activeDownloads) { -- 1.7.3.5 From alkim1234 at gmail.com Fri Jan 14 11:39:08 2011 From: alkim1234 at gmail.com (Albert Kim) Date: Fri, 14 Jan 2011 03:39:08 -0800 Subject: [Vimprobable-users] [PATCH 11/13] Made check for whether keyval is digit shorter. In-Reply-To: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> Message-ID: <1295005150-16318-12-git-send-email-alkim1234@gmail.com> --- main.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/main.c b/main.c index e54985a..2c6fd6a 100644 --- a/main.c +++ b/main.c @@ -501,6 +501,7 @@ inputbox_activate_cb(GtkEntry *entry, gpointer user_data) { gboolean inputbox_keypress_cb(GtkEntry *entry, GdkEventKey *event) { Arg a; + int numval; char count_buf[BUFFERSIZE]; switch (event->keyval) { @@ -528,9 +529,8 @@ inputbox_keypress_cb(GtkEntry *entry, GdkEventKey *event) { break; } - if (followTarget[0] && ((event->keyval >= GDK_1 && event->keyval <= GDK_9) - || (event->keyval >= GDK_KP_1 && event->keyval <= GDK_KP_9) - || ((event->keyval == GDK_0 || event->keyval == GDK_KP_0) && count))) { + numval = g_unichar_digit_value((gunichar) gdk_keyval_to_unicode(event->keyval)); + if (followTarget[0] && ((numval >= 1 && numval <= 9) || (numval == 0 && count))) { /* allow a zero as non-first number */ if (event->keyval >= GDK_KP_0 && event->keyval <= GDK_KP_9) count = (count ? count * 10 : 0) + (event->keyval - GDK_KP_0); -- 1.7.3.5 From alkim1234 at gmail.com Fri Jan 14 11:39:09 2011 From: alkim1234 at gmail.com (Albert Kim) Date: Fri, 14 Jan 2011 03:39:09 -0800 Subject: [Vimprobable-users] [PATCH 12/13] Used numval instead of keyval to calculate new count. In-Reply-To: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> Message-ID: <1295005150-16318-13-git-send-email-alkim1234@gmail.com> --- main.c | 5 +---- 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/main.c b/main.c index 2c6fd6a..9f1cca7 100644 --- a/main.c +++ b/main.c @@ -532,10 +532,7 @@ inputbox_keypress_cb(GtkEntry *entry, GdkEventKey *event) { numval = g_unichar_digit_value((gunichar) gdk_keyval_to_unicode(event->keyval)); if (followTarget[0] && ((numval >= 1 && numval <= 9) || (numval == 0 && count))) { /* allow a zero as non-first number */ - if (event->keyval >= GDK_KP_0 && event->keyval <= GDK_KP_9) - count = (count ? count * 10 : 0) + (event->keyval - GDK_KP_0); - else - count = (count ? count * 10 : 0) + (event->keyval - GDK_0); + count = (count ? count * 10 : 0) + numval; a.i = Silent; a.s = g_strdup_printf("vimprobable_update_hints(%d)", count); script(&a); -- 1.7.3.5 From alkim1234 at gmail.com Fri Jan 14 11:39:10 2011 From: alkim1234 at gmail.com (Albert Kim) Date: Fri, 14 Jan 2011 03:39:10 -0800 Subject: [Vimprobable-users] [PATCH 13/13] Fixed bug with not being able to press enter to follow single digit hints. In-Reply-To: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> Message-ID: <1295005150-16318-14-git-send-email-alkim1234@gmail.com> --- main.c | 11 ++++++++--- 1 files changed, 8 insertions(+), 3 deletions(-) diff --git a/main.c b/main.c index 9f1cca7..1cfd76e 100644 --- a/main.c +++ b/main.c @@ -442,10 +442,10 @@ inputbox_activate_cb(GtkEntry *entry, gpointer user_data) { a.i = HideCompletion; complete(&a); - if (length < 2) + if (length == 0) return; text = (char*)gtk_entry_get_text(entry); - if (text[0] == ':') { + if (length > 1 && text[0] == ':') { for (i = 0; i < LENGTH(commands); i++) { if (commands[i].cmd == NULL) break; @@ -476,7 +476,7 @@ inputbox_activate_cb(GtkEntry *entry, gpointer user_data) { } echo(&a); } - } else if ((forward = text[0] == '/') || text[0] == '?') { + } else if (length > 1 && ((forward = text[0] == '/') || text[0] == '?')) { webkit_web_view_unmark_text_matches(webview); #ifdef ENABLE_MATCH_HIGHLITING webkit_web_view_mark_text_matches(webview, &text[1], FALSE, 0); @@ -491,6 +491,11 @@ inputbox_activate_cb(GtkEntry *entry, gpointer user_data) { search_direction = forward; search_handle = g_strdup(&text[1]); #endif + } else if (count && (text[0] == '`' || text[0] == '~')) { + a.i = Silent; + a.s = g_strdup_printf("vimprobable_fire(%d)", count); + script(&a); + update_state(); } else return; if (!echo_active) -- 1.7.3.5 From alkim1234 at gmail.com Fri Jan 14 11:42:00 2011 From: alkim1234 at gmail.com (alkim1234 at gmail.com) Date: Fri, 14 Jan 2011 03:42:00 -0800 Subject: [Vimprobable-users] [PATCH 6/8] Added proper handling of numbers into new hinting system. In-Reply-To: <20110114095717.GD6937@abacus.soton.smoothwall.net> References: <1294995820-12957-1-git-send-email-alkim1234@gmail.com> <1294995820-12957-7-git-send-email-alkim1234@gmail.com> <20110114095717.GD6937@abacus.soton.smoothwall.net> Message-ID: <20110114114200.GA16451@elements.hsd1.ca.comcast.net> > You know what I'm going to tell you here, don't you? :) Remember our > discussion regarding your escape() patch, and macro definitions? Please > honour the ethos of that here. Good idea. By the way, do you know when the escape patch, or patches in general make it into the repo? From thomas at xteddy.org Fri Jan 14 13:09:29 2011 From: thomas at xteddy.org (Thomas Adam) Date: Fri, 14 Jan 2011 13:09:29 +0000 Subject: [Vimprobable-users] [PATCH 6/8] Added proper handling of numbers into new hinting system. In-Reply-To: <20110114114200.GA16451@elements.hsd1.ca.comcast.net> References: <1294995820-12957-1-git-send-email-alkim1234@gmail.com> <1294995820-12957-7-git-send-email-alkim1234@gmail.com> <20110114095717.GD6937@abacus.soton.smoothwall.net> <20110114114200.GA16451@elements.hsd1.ca.comcast.net> Message-ID: <20110114130928.GF6937@abacus.soton.smoothwall.net> On Fri, Jan 14, 2011 at 03:42:00AM -0800, alkim1234 at gmail.com wrote: > > You know what I'm going to tell you here, don't you? :) Remember our > > discussion regarding your escape() patch, and macro definitions? Please > > honour the ethos of that here. > > Good idea. By the way, do you know when the escape patch, or patches in general > make it into the repo? Whenever Hannes wakes up. Unfortunately I don't have commit access to the repositories on vimprobable.org myself. -- Thomas Adam From thomas at xteddy.org Fri Jan 14 17:04:09 2011 From: thomas at xteddy.org (Thomas Adam) Date: Fri, 14 Jan 2011 17:04:09 +0000 Subject: [Vimprobable-users] [PATCH 09/13] Made script() free arg->s where applicatable. In-Reply-To: <1295005150-16318-10-git-send-email-alkim1234@gmail.com> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> <1295005150-16318-10-git-send-email-alkim1234@gmail.com> Message-ID: <20110114170406.GH6937@abacus.soton.smoothwall.net> On Fri, Jan 14, 2011 at 03:39:06AM -0800, Albert Kim wrote: > + if (arg->s) g_free(arg->s); Style: if (arg->s) g_free(arg->s); > return FALSE; > } > if (arg->i != Silent && value) { > @@ -1426,6 +1425,7 @@ script(const Arg *arg) { > open_arg(&a); > } > } > + if (arg->s) g_free(arg->s); As above. You need only resend this specific patch, please. -- Thomas Adam From thomas at xteddy.org Fri Jan 14 17:06:25 2011 From: thomas at xteddy.org (Thomas Adam) Date: Fri, 14 Jan 2011 17:06:25 +0000 Subject: [Vimprobable-users] [PATCH 00/13] New Way to Handle Hinting In-Reply-To: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> Message-ID: <20110114170624.GI6937@abacus.soton.smoothwall.net> On Fri, Jan 14, 2011 at 03:38:57AM -0800, Albert Kim wrote: > I changed the hinting system so that it uses the inputbox instead of by keeping > track of each new keypress. There are two primary advantages to this: > > 1. The code becomes a lot simpler because GtkEntry takes care of the whole > unicode bit, and all we have to do is take care of updating the hints. > > 2. This allows for people to use their IMs to follow hints. > > EDIT: Updated for cleaner code. Couple of things from this: * Please don't re-roll entire patch series for patches which haven't changed. It makes reviewing easier to just keep updating the same thread for the patch with newer versions. * Some of your patches supply a shortlog only without a commit body. This is unacceptable. -- Thomas Adam From thomas at xteddy.org Fri Jan 14 17:10:21 2011 From: thomas at xteddy.org (Thomas Adam) Date: Fri, 14 Jan 2011 17:10:21 +0000 Subject: [Vimprobable-users] Small Escape Patch In-Reply-To: <20110111100106.GA21019@elements.hsd1.ca.comcast.net> References: <20110111092633.GA20305@elements.hsd1.ca.comcast.net> <20110111094033.GA2918@abacus.soton.smoothwall.net> <20110111100106.GA21019@elements.hsd1.ca.comcast.net> Message-ID: <20110114171019.GJ6937@abacus.soton.smoothwall.net> On Tue, Jan 11, 2011 at 02:01:06AM -0800, alkim1234 at gmail.com wrote: > > Ideally, this should be a separate patch. > > Thanks, I'll keep this in mind. > > > If we ever expand events like this -- to make other key combinations like > > this send an escape event, this macro will get ugly. Perhaps we should do > > something like the following? > > > > #define IS_ESCAPE(event) ((CLEAN(event->state) == 0 && IS_ESCAPE_KEY(s,k))) > > #define IS_ESCAPE_KEY(event) ((CLEAN(event->state) == GDK_CONTROL_MASK \ > > && event->keyval == GDK_bracketleft) || \ > > event->keyval == GDK_Escape) > > I assume you meant something like this: > > #define IS_ESCAPE(event) (IS_ESCAPE_KEY(CLEAN(event->state), event->keyval)) > #define IS_ESCAPE_KEY(s,k) ((s == GDK_CONTROL_MASK && k == GDK_bracketleft) || \ > ((s == 0) && (k == GDK_Escape))) > > Good idea. > > > Although macros like this become terrible over time, and I think in the > > future we should move to inline functions with key tables in the proper > > sense. > > Agreed. > > > Otherwise this looks OK. > > Great. I attached an updated patch incorporating your suggestion to the macro. Looks much better, thanks. Hannes -- I don't have any further comment on this. -- Thomas Adam From thomas at xteddy.org Fri Jan 14 17:21:53 2011 From: thomas at xteddy.org (Thomas Adam) Date: Fri, 14 Jan 2011 17:21:53 +0000 Subject: [Vimprobable-users] [PATCH 0/8] New Way to Handle Hinting In-Reply-To: <20110114104312.GD13654@elements.hsd1.ca.comcast.net> References: <1294995820-12957-1-git-send-email-alkim1234@gmail.com> <20110114090929.GA13064@elements.hsd1.ca.comcast.net> <20110114094933.GB6937@abacus.soton.smoothwall.net> <20110114104312.GD13654@elements.hsd1.ca.comcast.net> Message-ID: <20110114172152.GK6937@abacus.soton.smoothwall.net> On Fri, Jan 14, 2011 at 02:43:13AM -0800, alkim1234 at gmail.com wrote: > > > There is one issue with this. Due to the way some IMs work (SCIM in particular), > > > keypress events are not detected, and instead we may have to rely on keyrelease > > > events to see which number was pressed. Right now, the implementation is with > > > keypress events. > > > > Unfortunately, relying on keyrelease events is not guaranteed to work. > > Yes, but it's not quite as horrible as it seems. In my experience, when > attempting to follow hint 33, I usually press a 3 and then another 3, rather > than hold down 3 for a second and release. However, you're right that it is a > hack... It's not even that -- it's the fact that the not all XServers have support for it, and hence GTK won't have either. -- Thomas Adam From thomas at xteddy.org Fri Jan 14 17:25:40 2011 From: thomas at xteddy.org (Thomas Adam) Date: Fri, 14 Jan 2011 17:25:40 +0000 Subject: [Vimprobable-users] [PATCH 09/13] Made script() free arg->s where applicatable. In-Reply-To: <20110114170406.GH6937@abacus.soton.smoothwall.net> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> <1295005150-16318-10-git-send-email-alkim1234@gmail.com> <20110114170406.GH6937@abacus.soton.smoothwall.net> Message-ID: <20110114172539.GL6937@abacus.soton.smoothwall.net> On Fri, Jan 14, 2011 at 05:04:09PM +0000, Thomas Adam wrote: > On Fri, Jan 14, 2011 at 03:39:06AM -0800, Albert Kim wrote: > > + if (arg->s) g_free(arg->s); > > Style: > > if (arg->s) > g_free(arg->s); > > > return FALSE; > > } > > if (arg->i != Silent && value) { > > @@ -1426,6 +1425,7 @@ script(const Arg *arg) { > > open_arg(&a); > > } > > } > > + if (arg->s) g_free(arg->s); > > As above. > > You need only resend this specific patch, please. > > -- Thomas Adam Also, s/applicatable/applicable/ -- Thomas Adam From hannes at yllr.net Fri Jan 14 17:26:54 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Fri, 14 Jan 2011 18:26:54 +0100 Subject: [Vimprobable-users] [PATCH 6/8] Added proper handling of numbers into new hinting system. In-Reply-To: <20110114114200.GA16451@elements.hsd1.ca.comcast.net> References: <1294995820-12957-1-git-send-email-alkim1234@gmail.com> <1294995820-12957-7-git-send-email-alkim1234@gmail.com> <20110114095717.GD6937@abacus.soton.smoothwall.net> <20110114114200.GA16451@elements.hsd1.ca.comcast.net> Message-ID: <20110114182654.592a3b2b@workstation> alkim1234 at gmail.com wrote: > By the way, do you know when the escape patch, or patches in general > make it into the repo? Don't worry, I'm paying attention and reading all of this. I just want to avoid any hasty merges or replies in general, so I'd like to take my time to review everything you've submitted this weekend. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From thomas at xteddy.org Fri Jan 14 17:28:17 2011 From: thomas at xteddy.org (Thomas Adam) Date: Fri, 14 Jan 2011 17:28:17 +0000 Subject: [Vimprobable-users] [PATCH 13/13] Fixed bug with not being able to press enter to follow single digit hints. In-Reply-To: <1295005150-16318-14-git-send-email-alkim1234@gmail.com> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> <1295005150-16318-14-git-send-email-alkim1234@gmail.com> Message-ID: <20110114172815.GM6937@abacus.soton.smoothwall.net> On Fri, Jan 14, 2011 at 03:39:10AM -0800, Albert Kim wrote: > --- > main.c | 11 ++++++++--- > 1 files changed, 8 insertions(+), 3 deletions(-) > > diff --git a/main.c b/main.c > index 9f1cca7..1cfd76e 100644 > --- a/main.c > +++ b/main.c > @@ -442,10 +442,10 @@ inputbox_activate_cb(GtkEntry *entry, gpointer user_data) { > > a.i = HideCompletion; > complete(&a); > - if (length < 2) > + if (length == 0) > return; > text = (char*)gtk_entry_get_text(entry); > - if (text[0] == ':') { > + if (length > 1 && text[0] == ':') { > for (i = 0; i < LENGTH(commands); i++) { > if (commands[i].cmd == NULL) > break; Yeah -- the more I look at this, the more I hate how we're handling this here. Expect me to clean this patch up on top of this, by mailing out another approach. Prod me in a few days if you don't hear from me. -- Thomas Adam From alkim1234 at gmail.com Fri Jan 14 18:01:30 2011 From: alkim1234 at gmail.com (alkim1234 at gmail.com) Date: Fri, 14 Jan 2011 10:01:30 -0800 Subject: [Vimprobable-users] [PATCH 6/8] Added proper handling of numbers into new hinting system. In-Reply-To: <20110114182654.592a3b2b@workstation> References: <1294995820-12957-1-git-send-email-alkim1234@gmail.com> <1294995820-12957-7-git-send-email-alkim1234@gmail.com> <20110114095717.GD6937@abacus.soton.smoothwall.net> <20110114114200.GA16451@elements.hsd1.ca.comcast.net> <20110114182654.592a3b2b@workstation> Message-ID: <20110114180130.GA18423@elements.hsd1.ca.comcast.net> > > By the way, do you know when the escape patch, or patches in general > > make it into the repo? > > Don't worry, I'm paying attention and reading all of this. I just want > to avoid any hasty merges or replies in general, so I'd like to take my > time to review everything you've submitted this weekend. I see. Thanks. From alkim1234 at gmail.com Fri Jan 14 18:04:48 2011 From: alkim1234 at gmail.com (alkim1234 at gmail.com) Date: Fri, 14 Jan 2011 10:04:48 -0800 Subject: [Vimprobable-users] [PATCH 00/13] New Way to Handle Hinting In-Reply-To: <20110114170624.GI6937@abacus.soton.smoothwall.net> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> <20110114170624.GI6937@abacus.soton.smoothwall.net> Message-ID: <20110114180448.GB18423@elements.hsd1.ca.comcast.net> > * Please don't re-roll entire patch series for patches which haven't > changed. It makes reviewing easier to just keep updating the same thread > for the patch with newer versions. Okay, so do I just submit patches 9-13 in this case? Cover letter? > * Some of your patches supply a shortlog only without a commit body. This > is unacceptable. Even for really simple patches? Say I add a function prototype. Is the commit body still necessary? Thanks. From hannes at yllr.net Fri Jan 14 18:08:54 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Fri, 14 Jan 2011 19:08:54 +0100 Subject: [Vimprobable-users] [PATCH 00/13] New Way to Handle Hinting In-Reply-To: <20110114180448.GB18423@elements.hsd1.ca.comcast.net> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> <20110114170624.GI6937@abacus.soton.smoothwall.net> <20110114180448.GB18423@elements.hsd1.ca.comcast.net> Message-ID: <20110114190854.2082a705@workstation> alkim1234 at gmail.com wrote: > > * Some of your patches supply a shortlog only without a commit > > body. This is unacceptable. > > Even for really simple patches? Say I add a function prototype. Is > the commit body still necessary? If the subject sufficiently describes the commit, that's alright. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From alkim1234 at gmail.com Fri Jan 14 18:11:23 2011 From: alkim1234 at gmail.com (alkim1234 at gmail.com) Date: Fri, 14 Jan 2011 10:11:23 -0800 Subject: [Vimprobable-users] [PATCH 00/13] New Way to Handle Hinting In-Reply-To: <20110114190854.2082a705@workstation> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> <20110114170624.GI6937@abacus.soton.smoothwall.net> <20110114180448.GB18423@elements.hsd1.ca.comcast.net> <20110114190854.2082a705@workstation> Message-ID: <20110114181123.GA18646@elements.hsd1.ca.comcast.net> > > Even for really simple patches? Say I add a function prototype. Is > > the commit body still necessary? > > If the subject sufficiently describes the commit, that's alright. Noted. Thanks. From thomas at xteddy.org Fri Jan 14 19:06:12 2011 From: thomas at xteddy.org (Thomas Adam) Date: Fri, 14 Jan 2011 19:06:12 +0000 Subject: [Vimprobable-users] [PATCH 00/13] New Way to Handle Hinting In-Reply-To: <20110114180448.GB18423@elements.hsd1.ca.comcast.net> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> <20110114170624.GI6937@abacus.soton.smoothwall.net> <20110114180448.GB18423@elements.hsd1.ca.comcast.net> Message-ID: <20110114190610.GA2190@debian> On Fri, Jan 14, 2011 at 10:04:48AM -0800, alkim1234 at gmail.com wrote: > > * Please don't re-roll entire patch series for patches which haven't > > changed. It makes reviewing easier to just keep updating the same thread > > for the patch with newer versions. > > Okay, so do I just submit patches 9-13 in this case? Cover letter? > > > * Some of your patches supply a shortlog only without a commit body. This > > is unacceptable. > > Even for really simple patches? Say I add a function prototype. Is the commit > body still necessary? Even if it's a sentence -- it might seem trivial now, but when it comes to looking back on things, it can get annoying to realise there's no message in the body describing why. :) -- Thomas Adam -- "It was the cruelest game I've ever played and it's played inside my head." -- "Hush The Warmth", Gorky's Zygotic Mynci. From alkim1234 at gmail.com Fri Jan 14 19:06:43 2011 From: alkim1234 at gmail.com (alkim1234 at gmail.com) Date: Fri, 14 Jan 2011 11:06:43 -0800 Subject: [Vimprobable-users] [PATCH 00/13] New Way to Handle Hinting In-Reply-To: <20110114190610.GA2190@debian> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> <20110114170624.GI6937@abacus.soton.smoothwall.net> <20110114180448.GB18423@elements.hsd1.ca.comcast.net> <20110114190610.GA2190@debian> Message-ID: <20110114190643.GA7385@elements.hsd1.ca.comcast.net> > > > * Please don't re-roll entire patch series for patches which haven't > > > changed. It makes reviewing easier to just keep updating the same thread > > > for the patch with newer versions. > > > > Okay, so do I just submit patches 9-13 in this case? Cover letter? Can you answer this part? > > > * Some of your patches supply a shortlog only without a commit body. This > > > is unacceptable. > > > > Even for really simple patches? Say I add a function prototype. Is the commit > > body still necessary? > > Even if it's a sentence -- it might seem trivial now, but when it comes to > looking back on things, it can get annoying to realise there's no message in > the body describing why. :) Okay. From thomas at xteddy.org Fri Jan 14 19:15:40 2011 From: thomas at xteddy.org (Thomas Adam) Date: Fri, 14 Jan 2011 19:15:40 +0000 Subject: [Vimprobable-users] [PATCH 00/13] New Way to Handle Hinting In-Reply-To: <20110114190643.GA7385@elements.hsd1.ca.comcast.net> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> <20110114170624.GI6937@abacus.soton.smoothwall.net> <20110114180448.GB18423@elements.hsd1.ca.comcast.net> <20110114190610.GA2190@debian> <20110114190643.GA7385@elements.hsd1.ca.comcast.net> Message-ID: <20110114191538.GB2190@debian> On Fri, Jan 14, 2011 at 11:06:43AM -0800, alkim1234 at gmail.com wrote: > > > > * Please don't re-roll entire patch series for patches which haven't > > > > changed. It makes reviewing easier to just keep updating the same thread > > > > for the patch with newer versions. > > > > > > Okay, so do I just submit patches 9-13 in this case? Cover letter? > > Can you answer this part? Sure. :) If you've defined a patch-series already, and sent it out, some patches may well get more review than others. Since each patch is itself a separate email, often a patch is updated in that thread. So there's no need for a cover-letter here either, separately. Over time, what will happen is some patches in that series might have gone through three or four different revisions, others not, but what you'll find personally, is that changes to different patches will force you to re-roll other patches in the series as updates so they compile. So when you find yourself in that situation, it's common to re-roll the entire patch series again, often as: [PATCH V2] But at the end of discussions, it's natural sometimes to re-roll the series anyway, for review once more before things get shoved in the mainline repository. Does that make sense? Specifically in your example though, it becomes unmanagable to review thirteen different patches where only one or two of them have changed, as I won't have realised that, because the expectation is by resending the whole thing in some way, they've all changed. :) Please don't think me anal about this, I do a lot of this sort of work on different projects, and experience teaches me that even a two-patch series benefits from this. :) -- Thomas Adam -- "It was the cruelest game I've ever played and it's played inside my head." -- "Hush The Warmth", Gorky's Zygotic Mynci. From hannes at yllr.net Sat Jan 15 15:09:39 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 15 Jan 2011 16:09:39 +0100 Subject: [Vimprobable-users] [PATCH 1/1] Support Webkit's enable-page-cache setting In-Reply-To: <20101220203747.GA19159@shuttle.home> References: <20101220203747.GA19159@shuttle.home> Message-ID: <20110115160939.2617cdc2@laptop2.lan.localhost> Merged, thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From hannes at yllr.net Sat Jan 15 15:22:44 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 15 Jan 2011 16:22:44 +0100 Subject: [Vimprobable-users] [PATCH 1/1] Add field for customising HTTP Accept-Language header In-Reply-To: <4D2784D9.7050200@gmail.com> References: <4D275F5C.4010501@gmail.com> <20110107185552.GA2022@debian> <4D2784D9.7050200@gmail.com> Message-ID: <20110115162244.0e75ade5@laptop2.lan.localhost> Merged - it's working great for me! Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From hannes at yllr.net Sat Jan 15 15:40:34 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 15 Jan 2011 16:40:34 +0100 Subject: [Vimprobable-users] [PATCH 0/3] Cast pointer to macros for type-safety In-Reply-To: <20110107222508.GA7641@debian> References: <20110107222508.GA7641@debian> Message-ID: <20110115164034.6a7a994f@laptop2.lan.localhost> Merged -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From hannes at yllr.net Sat Jan 15 15:43:12 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 15 Jan 2011 16:43:12 +0100 Subject: [Vimprobable-users] ctrl-o, ctrl-i In-Reply-To: <20110111070820.GA15180@elements.hsd1.ca.comcast.net> References: <20110111070820.GA15180@elements.hsd1.ca.comcast.net> Message-ID: <20110115164312.13264c45@laptop2.lan.localhost> Hi! > I just wanted to point out that in the default config.h/keymap.h: > > goes forward > goes backward > > which is opposite of what typical vim users expect. Yes, this has been discussed several times. The question is: What makes sense? 'backward' is usually associated with 'left', 'forward' with 'right'. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From hannes at yllr.net Sat Jan 15 15:46:00 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 15 Jan 2011 16:46:00 +0100 Subject: [Vimprobable-users] Small Escape Patch In-Reply-To: <20110111092633.GA20305@elements.hsd1.ca.comcast.net> References: <20110111092633.GA20305@elements.hsd1.ca.comcast.net> Message-ID: <20110115164600.10380ed0@laptop2.lan.localhost> Hi! alkim1234 at gmail.com wrote: > This is a small patch provides the macro IS_ESCAPE to check whether a > GdkEventKey should be considered as an escape event. This patch also > adds as an escape event. What's the rationale behind adding C-[ as escape key in the default configuration? I'm not against it per se, just want to know the reason. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From hannes at yllr.net Sat Jan 15 15:53:38 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 15 Jan 2011 16:53:38 +0100 Subject: [Vimprobable-users] [PATCH 00/13] New Way to Handle Hinting In-Reply-To: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> Message-ID: <20110115165338.54c7a86e@laptop2.lan.localhost> Compile time warning: main.c: In function ?inputbox_keypress_cb?: main.c:510: warning: unused variable ?count_buf? I'll start functional testing now. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From thomas at xteddy.org Sat Jan 15 16:07:06 2011 From: thomas at xteddy.org (Thomas Adam) Date: Sat, 15 Jan 2011 16:07:06 +0000 Subject: [Vimprobable-users] Small Escape Patch In-Reply-To: <20110115164600.10380ed0@laptop2.lan.localhost> References: <20110111092633.GA20305@elements.hsd1.ca.comcast.net> <20110115164600.10380ed0@laptop2.lan.localhost> Message-ID: <20110115160704.GA2161@debian> On Sat, Jan 15, 2011 at 04:46:00PM +0100, Hannes Sch??ller wrote: > Hi! > > alkim1234 at gmail.com wrote: > > This is a small patch provides the macro IS_ESCAPE to check whether a > > GdkEventKey should be considered as an escape event. This patch also > > adds as an escape event. > > What's the rationale behind adding C-[ as escape key in the default > configuration? I'm not against it per se, just want to know the reason. In vim, by default, C-[ also sends escape. But we do need to be careful here, I think. I mean, this *isn't* Vim, it's *like* Vim, but I am dubious also by setting an adhoc preference as to which parts of Vim we're copying or not. Especially in terms of bloating out the code each time. -- Thomas Adam -- "It was the cruelest game I've ever played and it's played inside my head." -- "Hush The Warmth", Gorky's Zygotic Mynci. From hannes at yllr.net Sat Jan 15 16:10:02 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 15 Jan 2011 17:10:02 +0100 Subject: [Vimprobable-users] [PATCH 00/13] New Way to Handle Hinting In-Reply-To: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> Message-ID: <20110115171002.0135aeda@laptop2.lan.localhost> On the whole, this looks like an excellent improvement to me! It will certainly help compatibility with different languages and keyboard layouts. Remaining complaints: - Backspace handling is messy. If I activate hinting, enter one number and then remove it again (backspace), the hints disappear (because the backtick is deleted from the input box). This shouldn't happen. (This is handled correctly when just typing text and removing it again.) If I activate hinting, enter a letter and then a number and hit backspace, the letter is removed, but the number stays. There should be a way to correct the number I entered. - ` and ~ aren't good keys to use, in my opinion. I'm using a 'dead keys' layout which makes it impossible to trigger these functions. Even with 'nodeadkeys', my keyboard layout wouldn't use Shift to trigger ~. Usage of such keys goes contrary to the goal of becoming independent of a specific keyboard layout, in my opinion. - Speaking of ~, as far as I can see this does the same as uppercase F, right? I'm a little confused about the description talking about 'opening in the background'. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From hannes at yllr.net Sat Jan 15 16:15:49 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 15 Jan 2011 17:15:49 +0100 Subject: [Vimprobable-users] [PATCH 00/13] New Way to Handle Hinting In-Reply-To: <20110115171002.0135aeda@laptop2.lan.localhost> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> <20110115171002.0135aeda@laptop2.lan.localhost> Message-ID: <20110115171549.450fb99e@laptop2.lan.localhost> Hannes Sch?ller wrote: > - Backspace handling is messy. If I activate hinting, enter one number > and then remove it again (backspace), the hints disappear (because > the backtick is deleted from the input box). This shouldn't happen. > (This is handled correctly when just typing text and removing it > again.) If I activate hinting, enter a letter and then a number and > hit backspace, the letter is removed, but the number stays. There > should be a way to correct the number I entered. To save you the confusion: I'm aware that one key can't really fulfill two functions. I'd be ok with the way backspace currently works in your patch (i.e. just working on the input box) if there was another way of removing the last digit again (e.g. Del key or something). Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From kasmra at vimprobable.mail.kapsi.fi Sat Jan 15 17:52:18 2011 From: kasmra at vimprobable.mail.kapsi.fi (Sami =?iso-8859-1?Q?M=E4ki?=) Date: Sat, 15 Jan 2011 19:52:18 +0200 Subject: [Vimprobable-users] ctrl-o, ctrl-i In-Reply-To: <20110115164312.13264c45@laptop2.lan.localhost> References: <20110111070820.GA15180@elements.hsd1.ca.comcast.net> <20110115164312.13264c45@laptop2.lan.localhost> Message-ID: <20110115175218.GA31169@debel> On Sat, Jan 15, 2011 at 04:43:12PM +0100, Hannes Sch?ller wrote: > Hi! > > > I just wanted to point out that in the default config.h/keymap.h: > > > > goes forward > > goes backward > > > > which is opposite of what typical vim users expect. > > Yes, this has been discussed several times. The question is: What makes > sense? 'backward' is usually associated with 'left', 'forward' with > 'right'. Yes, it's beating on a dead horse but once again: This conflicts with a Vim user's muscle memory. I think that's the real issue. Not the usual Average Joe logic of left==back/right==forward. -- Sami :wq From mtreibton at googlemail.com Sun Jan 16 16:01:28 2011 From: mtreibton at googlemail.com (Michael Treibton) Date: Sun, 16 Jan 2011 16:01:28 +0000 Subject: [Vimprobable-users] vimprobable2 inside tabbed makes vimprobable2 freeze Message-ID: hi everyone, i've a strange problem when running vimprobable2 inside tabbed. The version of vimprobable2 is current git, and the version of tabbed is 0.3 (which is the latest release). When I navigate to most sites in vimprobable2 inside tabbed, the page will start to load, and then go blank. Resizing the tabbed window doesn't force a refresh. The vimprobable process is still running, but it unresponsive. Attaching strace produces no output, yet running vimprobable2 *outside* of tabbed and going to the same website, it all works fine. has anyone else seen this? sites in patricular which show this gmail.com and github.com, although sometimes they'll work inside tabbed, other times not. i've checked the logs, and the only output from vimprobable2 is stuff like this: ** Message: useQuirks: 0 / 0 / www.github.com repeated over and over, but i get the same logs in and out of tabbed. this is running on debian linux (unstable) but i've always had this problem running vimprobable2 inside tabbed. Michael From hannes at yllr.net Sun Jan 16 16:05:28 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sun, 16 Jan 2011 17:05:28 +0100 Subject: [Vimprobable-users] vimprobable2 inside tabbed makes vimprobable2 freeze In-Reply-To: References: Message-ID: <20110116170528.5010f061@workstation> Hi! Michael Treibton wrote: > When I navigate to most sites in vimprobable2 inside tabbed, the page > will start to load, and then go blank. Can't reproduce. Any special settings in the browser or in tabbed? Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From alkim1234 at gmail.com Fri Jan 21 05:36:51 2011 From: alkim1234 at gmail.com (alkim1234 at gmail.com) Date: Thu, 20 Jan 2011 21:36:51 -0800 Subject: [Vimprobable-users] Small Escape Patch In-Reply-To: <20110115160704.GA2161@debian> References: <20110111092633.GA20305@elements.hsd1.ca.comcast.net> <20110115164600.10380ed0@laptop2.lan.localhost> <20110115160704.GA2161@debian> Message-ID: <20110121053651.GA28375@elements.hsd1.ca.comcast.net> On Sat, Jan 15, 2011 at 04:07:06PM +0000, Thomas Adam wrote: > On Sat, Jan 15, 2011 at 04:46:00PM +0100, Hannes Sch??ller wrote: > > Hi! > > > > alkim1234 at gmail.com wrote: > > > This is a small patch provides the macro IS_ESCAPE to check whether a > > > GdkEventKey should be considered as an escape event. This patch also > > > adds as an escape event. > > > > What's the rationale behind adding C-[ as escape key in the default > > configuration? I'm not against it per se, just want to know the reason. > > In vim, by default, C-[ also sends escape. > > But we do need to be careful here, I think. I mean, this *isn't* Vim, it's > *like* Vim, but I am dubious also by setting an adhoc preference as to which > parts of Vim we're copying or not. Especially in terms of bloating out the > code each time. Actually, it's pretty standard for C-[ to send the escape signal. Most terminal emulators support it and vimperator also supports it. While I agree with the sentiment that code bloating is bad, I find that this is a rather small change, and a lot of my friends and I always use C-[ to escape out of a mode in vim and vimperator. From alkim1234 at gmail.com Fri Jan 21 05:38:46 2011 From: alkim1234 at gmail.com (alkim1234 at gmail.com) Date: Thu, 20 Jan 2011 21:38:46 -0800 Subject: [Vimprobable-users] [PATCH 0/8] New Way to Handle Hinting In-Reply-To: <20110114172152.GK6937@abacus.soton.smoothwall.net> References: <1294995820-12957-1-git-send-email-alkim1234@gmail.com> <20110114090929.GA13064@elements.hsd1.ca.comcast.net> <20110114094933.GB6937@abacus.soton.smoothwall.net> <20110114104312.GD13654@elements.hsd1.ca.comcast.net> <20110114172152.GK6937@abacus.soton.smoothwall.net> Message-ID: <20110121053846.GB28375@elements.hsd1.ca.comcast.net> On Fri, Jan 14, 2011 at 05:21:53PM +0000, Thomas Adam wrote: > On Fri, Jan 14, 2011 at 02:43:13AM -0800, alkim1234 at gmail.com wrote: > > > > There is one issue with this. Due to the way some IMs work (SCIM in particular), > > > > keypress events are not detected, and instead we may have to rely on keyrelease > > > > events to see which number was pressed. Right now, the implementation is with > > > > keypress events. > > > > > > Unfortunately, relying on keyrelease events is not guaranteed to work. > > > > Yes, but it's not quite as horrible as it seems. In my experience, when > > attempting to follow hint 33, I usually press a 3 and then another 3, rather > > than hold down 3 for a second and release. However, you're right that it is a > > hack... > > It's not even that -- it's the fact that the not all XServers have support > for it, and hence GTK won't have either. Oh, I didn't know this. Do you have some sort of reference as to where you found this out? Albert Kim From alkim1234 at gmail.com Fri Jan 21 05:52:57 2011 From: alkim1234 at gmail.com (alkim1234 at gmail.com) Date: Thu, 20 Jan 2011 21:52:57 -0800 Subject: [Vimprobable-users] [PATCH 00/13] New Way to Handle Hinting In-Reply-To: <20110114191538.GB2190@debian> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> <20110114170624.GI6937@abacus.soton.smoothwall.net> <20110114180448.GB18423@elements.hsd1.ca.comcast.net> <20110114190610.GA2190@debian> <20110114190643.GA7385@elements.hsd1.ca.comcast.net> <20110114191538.GB2190@debian> Message-ID: <20110121055257.GC28375@elements.hsd1.ca.comcast.net> Thanks. I think I get it a bit more now. On Fri, Jan 14, 2011 at 07:15:40PM +0000, Thomas Adam wrote: > On Fri, Jan 14, 2011 at 11:06:43AM -0800, alkim1234 at gmail.com wrote: > > > > > * Please don't re-roll entire patch series for patches which haven't > > > > > changed. It makes reviewing easier to just keep updating the same thread > > > > > for the patch with newer versions. > > > > > > > > Okay, so do I just submit patches 9-13 in this case? Cover letter? > > > > Can you answer this part? > > Sure. :) > > If you've defined a patch-series already, and sent it out, some patches > may well get more review than others. Since each patch is itself a separate > email, often a patch is updated in that thread. So there's no need for a > cover-letter here either, separately. > > Over time, what will happen is some patches in that series might have gone > through three or four different revisions, others not, but what you'll find > personally, is that changes to different patches will force you to re-roll > other patches in the series as updates so they compile. > > So when you find yourself in that situation, it's common to re-roll the > entire patch series again, often as: > > [PATCH V2] > > But at the end of discussions, it's natural sometimes to re-roll the series > anyway, for review once more before things get shoved in the mainline > repository. > > Does that make sense? Specifically in your example though, it becomes > unmanagable to review thirteen different patches where only one or two of > them have changed, as I won't have realised that, because the expectation is > by resending the whole thing in some way, they've all changed. :) > > Please don't think me anal about this, I do a lot of this sort of work on > different projects, and experience teaches me that even a two-patch series > benefits from this. :) > > -- Thomas Adam > > -- > "It was the cruelest game I've ever played and it's played inside my head." > -- "Hush The Warmth", Gorky's Zygotic Mynci. > _______________________________________________ > Vimprobable-users mailing list > Vimprobable-users at vimprobable.org > http://vimprobable.org/mailman/listinfo/vimprobable-users From alkim1234 at gmail.com Fri Jan 21 05:57:12 2011 From: alkim1234 at gmail.com (alkim1234 at gmail.com) Date: Thu, 20 Jan 2011 21:57:12 -0800 Subject: [Vimprobable-users] [PATCH 09/13] Made script() free arg->s where applicatable. In-Reply-To: <20110114170406.GH6937@abacus.soton.smoothwall.net> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> <1295005150-16318-10-git-send-email-alkim1234@gmail.com> <20110114170406.GH6937@abacus.soton.smoothwall.net> Message-ID: <20110121055712.GD28375@elements.hsd1.ca.comcast.net> Attached. On Fri, Jan 14, 2011 at 05:04:09PM +0000, Thomas Adam wrote: > On Fri, Jan 14, 2011 at 03:39:06AM -0800, Albert Kim wrote: > > + if (arg->s) g_free(arg->s); > > Style: > > if (arg->s) > g_free(arg->s); > > > return FALSE; > > } > > if (arg->i != Silent && value) { > > @@ -1426,6 +1425,7 @@ script(const Arg *arg) { > > open_arg(&a); > > } > > } > > + if (arg->s) g_free(arg->s); > > As above. > > You need only resend this specific patch, please. > > -- Thomas Adam -------------- next part -------------- >From 3cc19296e3f1bc21c7d9a8f69103656faf2df63e Mon Sep 17 00:00:00 2001 From: Albert Kim Date: Fri, 14 Jan 2011 02:28:01 -0800 Subject: [PATCH 09/14] Made script() free arg->s where applicatable. --- main.c | 18 ++++++++++-------- 1 files changed, 10 insertions(+), 8 deletions(-) diff --git a/main.c b/main.c index 1f9a7c5..f41a2b0 100644 --- a/main.c +++ b/main.c @@ -193,7 +193,7 @@ ascii_bar(int total, int state, char *string) { void webview_load_committed_cb(WebKitWebView *webview, WebKitWebFrame *frame, gpointer user_data) { - Arg a = { .i = Silent, .s = JS_SETUP_HINTS }; + Arg a = { .i = Silent, .s = g_strdup(JS_SETUP_HINTS) }; const char *uri = webkit_web_view_get_uri(webview); update_url(uri); @@ -202,7 +202,7 @@ webview_load_committed_cb(WebKitWebView *webview, WebKitWebFrame *frame, gpointe void webview_load_finished_cb(WebKitWebView *webview, WebKitWebFrame *frame, gpointer user_data) { - Arg a = { .i = Silent, .s = JS_SETUP_INPUT_FOCUS }; + Arg a = { .i = Silent, .s = g_strdup(JS_SETUP_INPUT_FOCUS) }; if (HISTORY_MAX_ENTRIES > 0) history(); @@ -666,7 +666,6 @@ inputbox_keypress_cb(GtkEntry *entry, GdkEventKey *event) { a.s = g_strconcat("vimprobable_update_hints(", count_buf, ")", NULL); script(&a); update_state(); - g_free(a.s); return TRUE; } @@ -730,19 +729,18 @@ static gboolean inputbox_changed_cb(GtkEditable *entry, gpointer user_data) { } else if (gtk_widget_is_focus(GTK_WIDGET(entry)) && length >= 1 && (text[0] == '`' || text[0] == '~')) { a.i = Silent; - a.s = "vimprobable_cleanup()"; + a.s = g_strdup("vimprobable_cleanup()"); script(&a); a.i = Silent; a.s = g_strconcat("vimprobable_show_hints('", text + 1, "')", NULL); script(&a); - free(a.s); return TRUE; } else if (length == 0 && followTarget[0]) { memset(followTarget, 0, 8); a.i = Silent; - a.s = "vimprobable_clear()"; + a.s = g_strdup("vimprobable_clear()"); script(&a); count = 0; update_state(); @@ -1041,7 +1039,7 @@ input(const Arg *arg) { memset(followTarget, 0, 0); strncpy(followTarget, arg->s[0] == '`' ? "current" : "new", 8); a.i = Silent; - a.s = "vimprobable_show_hints()"; + a.s = g_strdup("vimprobable_show_hints()"); script(&a); } @@ -1313,7 +1311,7 @@ set(const Arg *arg) { memset(followTarget, 0, 8); strncpy(followTarget, arg->s, 8); a.i = Silent; - a.s = "vimprobable_show_hints()"; + a.s = g_strdup("vimprobable_show_hints()"); script(&a); break; default: @@ -1396,6 +1394,8 @@ script(const Arg *arg) { jsapi_evaluate_script(arg->s, &value, &message); if (message) { set_error(message); + if (arg->s) + g_free(arg->s); return FALSE; } if (arg->i != Silent && value) { @@ -1426,6 +1426,8 @@ script(const Arg *arg) { open_arg(&a); } } + if (arg->s) + g_free(arg->s); g_free(value); return TRUE; } -- 1.7.3.5 From alkim1234 at gmail.com Fri Jan 21 05:57:44 2011 From: alkim1234 at gmail.com (alkim1234 at gmail.com) Date: Thu, 20 Jan 2011 21:57:44 -0800 Subject: [Vimprobable-users] [PATCH 13/13] Fixed bug with not being able to press enter to follow single digit hints. In-Reply-To: <20110114172815.GM6937@abacus.soton.smoothwall.net> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> <1295005150-16318-14-git-send-email-alkim1234@gmail.com> <20110114172815.GM6937@abacus.soton.smoothwall.net> Message-ID: <20110121055744.GE28375@elements.hsd1.ca.comcast.net> On Fri, Jan 14, 2011 at 05:28:17PM +0000, Thomas Adam wrote: > On Fri, Jan 14, 2011 at 03:39:10AM -0800, Albert Kim wrote: > > --- > > main.c | 11 ++++++++--- > > 1 files changed, 8 insertions(+), 3 deletions(-) > > > > diff --git a/main.c b/main.c > > index 9f1cca7..1cfd76e 100644 > > --- a/main.c > > +++ b/main.c > > @@ -442,10 +442,10 @@ inputbox_activate_cb(GtkEntry *entry, gpointer user_data) { > > > > a.i = HideCompletion; > > complete(&a); > > - if (length < 2) > > + if (length == 0) > > return; > > text = (char*)gtk_entry_get_text(entry); > > - if (text[0] == ':') { > > + if (length > 1 && text[0] == ':') { > > for (i = 0; i < LENGTH(commands); i++) { > > if (commands[i].cmd == NULL) > > break; > > Yeah -- the more I look at this, the more I hate how we're handling this > here. Expect me to clean this patch up on top of this, by mailing out > another approach. Prod me in a few days if you don't hear from me. Any thoughts? Albert Kim From alkim1234 at gmail.com Fri Jan 21 05:58:23 2011 From: alkim1234 at gmail.com (alkim1234 at gmail.com) Date: Thu, 20 Jan 2011 21:58:23 -0800 Subject: [Vimprobable-users] [PATCH 00/13] New Way to Handle Hinting In-Reply-To: <20110115165338.54c7a86e@laptop2.lan.localhost> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> <20110115165338.54c7a86e@laptop2.lan.localhost> Message-ID: <20110121055823.GF28375@elements.hsd1.ca.comcast.net> Patch for this attached. On Sat, Jan 15, 2011 at 04:53:38PM +0100, Hannes Sch?ller wrote: > Compile time warning: > > main.c: In function ?inputbox_keypress_cb?: > main.c:510: warning: unused variable ?count_buf? > > I'll start functional testing now. > > Hannes > _______________________________________________ > Vimprobable-users mailing list > Vimprobable-users at vimprobable.org > http://vimprobable.org/mailman/listinfo/vimprobable-users -------------- next part -------------- >From 5aa7e229287825aeaadfce2d509a63afd3e23da2 Mon Sep 17 00:00:00 2001 From: Albert Kim Date: Thu, 20 Jan 2011 21:53:26 -0800 Subject: [PATCH 14/14] Removed compile time warning about count_buf not being used. --- main.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/main.c b/main.c index f521298..9e9bb70 100644 --- a/main.c +++ b/main.c @@ -507,7 +507,6 @@ gboolean inputbox_keypress_cb(GtkEntry *entry, GdkEventKey *event) { Arg a; int numval; - char count_buf[BUFFERSIZE]; switch (event->keyval) { case GDK_Escape: -- 1.7.3.5 From alkim1234 at gmail.com Fri Jan 21 06:12:27 2011 From: alkim1234 at gmail.com (alkim1234 at gmail.com) Date: Thu, 20 Jan 2011 22:12:27 -0800 Subject: [Vimprobable-users] [PATCH 00/13] New Way to Handle Hinting In-Reply-To: <20110115171002.0135aeda@laptop2.lan.localhost> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> <20110115171002.0135aeda@laptop2.lan.localhost> Message-ID: <20110121061227.GG28375@elements.hsd1.ca.comcast.net> > - ` and ~ aren't good keys to use, in my opinion. I'm using a 'dead > keys' layout which makes it impossible to trigger these functions. > Even with 'nodeadkeys', my keyboard layout wouldn't use Shift to > trigger ~. Usage of such keys goes contrary to the goal of becoming > independent of a specific keyboard layout, in my opinion. I expect most users to just use f or F. ` was added because when a user presses f, the inputbox starts with `, to indicate that hintmode has been triggered, I couldn't think of a different symbol to use (what do you recommend)? Because ` indicates hintmode, I thought pressing ` could also start hintmode. Same for ~, except links will be followed in a new window. We can use different keys/symbols if you want. What do you suggest? > - Speaking of ~, as far as I can see this does the same as uppercase F, > right? I'm a little confused about the description talking about > 'opening in the background'. Explanation about redundancy in previous paragraph. What I mean by open in the background is simply open in another window. - Also, there is the issue of number keypresses not being detected in some languages, like Japanese. However, these keypresses are detected in the changed signal, so we can probably use inputbox_changed_cb to fix this issue in some way. From alkim1234 at gmail.com Fri Jan 21 06:16:59 2011 From: alkim1234 at gmail.com (alkim1234 at gmail.com) Date: Thu, 20 Jan 2011 22:16:59 -0800 Subject: [Vimprobable-users] [PATCH 00/13] New Way to Handle Hinting In-Reply-To: <20110115171549.450fb99e@laptop2.lan.localhost> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> <20110115171002.0135aeda@laptop2.lan.localhost> <20110115171549.450fb99e@laptop2.lan.localhost> Message-ID: <20110121061659.GH28375@elements.hsd1.ca.comcast.net> On Sat, Jan 15, 2011 at 05:15:49PM +0100, Hannes Sch?ller wrote: > Hannes Sch?ller wrote: > > - Backspace handling is messy. If I activate hinting, enter one number > > and then remove it again (backspace), the hints disappear (because > > the backtick is deleted from the input box). This shouldn't happen. > > (This is handled correctly when just typing text and removing it > > again.) If I activate hinting, enter a letter and then a number and > > hit backspace, the letter is removed, but the number stays. There > > should be a way to correct the number I entered. I actually wanted removal of the backtick to be a trigger to go into normal. I was thinking about how the removal (via backspace) of the colon causes command mode to go into normal mode. What do you think? > To save you the confusion: I'm aware that one key can't really fulfill > two functions. I'd be ok with the way backspace currently works in your > patch (i.e. just working on the input box) if there was another way of > removing the last digit again (e.g. Del key or something). Should I try to add this as part of this patch series, or in a new patch series? From hannes at yllr.net Mon Jan 24 19:37:38 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Mon, 24 Jan 2011 20:37:38 +0100 Subject: [Vimprobable-users] [PATCH 00/13] New Way to Handle Hinting In-Reply-To: <20110121061227.GG28375@elements.hsd1.ca.comcast.net> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> <20110115171002.0135aeda@laptop2.lan.localhost> <20110121061227.GG28375@elements.hsd1.ca.comcast.net> Message-ID: <20110124203738.1cf04d88@laptop2.lan.localhost> Hi! alkim1234 at gmail.com wrote: > > - ` and ~ aren't good keys to use, in my opinion. I'm using a 'dead > > keys' layout which makes it impossible to trigger these functions. > > Even with 'nodeadkeys', my keyboard layout wouldn't use Shift to > > trigger ~. Usage of such keys goes contrary to the goal of > > becoming independent of a specific keyboard layout, in my opinion. > > I expect most users to just use f or F. ` was added because when a > user presses f, the inputbox starts with `, to indicate that hintmode > has been triggered, I couldn't think of a different symbol to use > (what do you recommend)? Because ` indicates hintmode, I thought > pressing ` could also start hintmode. Same for ~, except links will > be followed in a new window. We can use different keys/symbols if you > want. What do you suggest? I agree with your sentiments that the indicator in the input line should be the same key triggering this. I also agree that since f and F will still be there, it's not a matter of life or death. That said, is there any reason speaking against simple characters like "." and ","? "." activates link hinting in Elinks, for example. "," could be used to activate hinting to open links in a new window. alkim1234 at gmail.com wrote: > On Sat, Jan 15, 2011 at 05:15:49PM +0100, Hannes Sch?ller wrote: > > Hannes Sch?ller wrote: > > > - Backspace handling is messy. If I activate hinting, enter one > > > number and then remove it again (backspace), the hints disappear > > > (because the backtick is deleted from the input box). This > > > shouldn't happen. (This is handled correctly when just typing > > > text and removing it again.) If I activate hinting, enter a > > > letter and then a number and hit backspace, the letter is > > > removed, but the number stays. There should be a way to correct > > > the number I entered. > > I actually wanted removal of the backtick to be a trigger to go into > normal. I was thinking about how the removal (via backspace) of the > colon causes command mode to go into normal mode. What do you think? Agreed, this makes sense. See next point. > > To save you the confusion: I'm aware that one key can't really > > fulfill two functions. I'd be ok with the way backspace currently > > works in your patch (i.e. just working on the input box) if there > > was another way of removing the last digit again (e.g. Del key or > > something). > > Should I try to add this as part of this patch series, or in a new > patch series? To elaborate: I'm not claiming this is handled very well in the browser right now. It's just that I see the potential to make it much better with your approach, which is the reason why I keep coming back to this point. I agree that backspace should always be handled by the input box. Removal of the starting character of the hinting mode should drop the browser back to normal mode. In addition, some other key (which is not required in the input box) should trigger the removal of the last number entered. I'm not sure how this could be done, though, as the inputbox has got focus and your way of handling this doesn't rely on keypress events anymore. I'm sure it's possible, though. I don't care much in what way you get this functionality across. I don't mind some history through incremental patchsets, but you're also welcome to re-do the existing series. I'd even be fine with a simple patchfile you send in addition. Whatever suits you - I'm sure I will be able to handle it. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From thayerwilliams at gmail.com Tue Jan 25 22:43:02 2011 From: thayerwilliams at gmail.com (Thayer Williams) Date: Tue, 25 Jan 2011 14:43:02 -0800 Subject: [Vimprobable-users] Disable CSS stylesheets on-the-fly Message-ID: <20110125224302.GA4557@msi.domain.invaliddomain.invalid> Hi there, I just recently started using Vimprobable and I'm trying to figure out a way to disable embedded stylesheets on-the-fly. Vimperator accomplishes this with :set invum, which calls some internal Firefox function. I've done some preliminary research into Webkit, though I haven't yet determined whether it's possible to do this with an internal function call. Google Chrome doesn't offer this ability, but it appears that Safari does (via the developer mode/settings). Also, there are javascript bookmarklets[1] in the wild which accomplish nearly the same thing, but I don't see a clean way of implementing it into vimprobable and frankly, I'd rather steer clear of javascript hacks entirely. Anyway, as a web developer (and a picky content reader), it's incredibly handy to be able to disable CSS rendering on a per-page basis in order to: a) view the raw, semantic structure of a page; and b) turn off visually unpleasant/unreadable stylesheets Has this feature been discussed before? Has anyone found a clean way of implementing it? [1]:http://www.greytower.net/archive/articles/disablecss.html From thomas at xteddy.org Tue Jan 25 23:26:35 2011 From: thomas at xteddy.org (Thomas Adam) Date: Tue, 25 Jan 2011 23:26:35 +0000 Subject: [Vimprobable-users] Disable CSS stylesheets on-the-fly In-Reply-To: <20110125224302.GA4557@msi.domain.invaliddomain.invalid> References: <20110125224302.GA4557@msi.domain.invaliddomain.invalid> Message-ID: <20110125232633.GA2171@debian> On Tue, Jan 25, 2011 at 02:43:02PM -0800, Thayer Williams wrote: > Hi there, > > I just recently started using Vimprobable and I'm trying to figure out a way > to disable embedded stylesheets on-the-fly. Vimperator accomplishes this > with :set invum, which calls some internal Firefox function. I've done some > preliminary research into Webkit, though I haven't yet determined whether > it's possible to do this with an internal function call. I don't believe it's possible to do this in webkit -- at least not the GTK port. The best thing you can do is set the user-stylesheet property to /dev/null which likely won't achieve anything like what you're after. > a) view the raw, semantic structure of a page; and > b) turn off visually unpleasant/unreadable stylesheets You might need to use Dillo or ELinks here for that. > Has this feature been discussed before? Has anyone found a clean way of > implementing it? Not without digging deep into the internals of webkit, no. -- Thomas Adam -- "It was the cruelest game I've ever played and it's played inside my head." -- "Hush The Warmth", Gorky's Zygotic Mynci. From thayerwilliams at gmail.com Wed Jan 26 03:59:45 2011 From: thayerwilliams at gmail.com (Thayer Williams) Date: Tue, 25 Jan 2011 19:59:45 -0800 Subject: [Vimprobable-users] Disable CSS stylesheets on-the-fly In-Reply-To: <20110125232633.GA2171@debian> References: <20110125224302.GA4557@msi.domain.invaliddomain.invalid> <20110125232633.GA2171@debian> Message-ID: On 25/01/2011, Thomas Adam wrote: > On Tue, Jan 25, 2011 at 02:43:02PM -0800, Thayer Williams wrote: >> Hi there, >> >> I just recently started using Vimprobable and I'm trying to figure out a >> way >> to disable embedded stylesheets on-the-fly. Vimperator accomplishes this >> with :set invum, which calls some internal Firefox function. I've done >> some >> preliminary research into Webkit, though I haven't yet determined whether >> it's possible to do this with an internal function call. > > I don't believe it's possible to do this in webkit -- at least not the GTK > port. > > The best thing you can do is set the user-stylesheet property to /dev/null > which likely won't achieve anything like what you're after. Yeah, that would simply be the same as having a blank user-style.css; it wouldn't effect any author stylesheets. >> a) view the raw, semantic structure of a page; and >> b) turn off visually unpleasant/unreadable stylesheets > > You might need to use Dillo or ELinks here for that. > >> Has this feature been discussed before? Has anyone found a clean way of >> implementing it? > > Not without digging deep into the internals of webkit, no. Seems there's some method for this built into webkit which is also used by jQuery to control stylesheet rendering, specifically HTMLStyleElement.disabled; though I don't know whether that applies to the GTK port. I'll take a closer look when I get the chance. On a similar note, do you know whether there are any plans to implement user-javascript, similar to the existing user-style functionality? I hate javascript-heavy websites just as much as the next guy, but it's handy to script stuff on the user-side sometimes (controlling websites, userscripts, etc.) Regardless, thanks for the feedback. From thomas at xteddy.org Wed Jan 26 10:01:29 2011 From: thomas at xteddy.org (Thomas Adam) Date: Wed, 26 Jan 2011 10:01:29 +0000 Subject: [Vimprobable-users] Disable CSS stylesheets on-the-fly In-Reply-To: References: <20110125224302.GA4557@msi.domain.invaliddomain.invalid> <20110125232633.GA2171@debian> Message-ID: <20110126100127.GB2949@abacus.soton.smoothwall.net> On Tue, Jan 25, 2011 at 07:59:45PM -0800, Thayer Williams wrote: > Seems there's some method for this built into webkit which is also > used by jQuery to control stylesheet rendering, specifically > HTMLStyleElement.disabled; though I don't know whether that applies to > the GTK port. I'll take a closer look when I get the chance. The only way you can do it is with JavaScript, because there is no direct DOM manipulation code in the GTK port of Webkit. I think you're on to a loosing streak though trying to do it this way -- it's probably going to be a lot of work. > On a similar note, do you know whether there are any plans to > implement user-javascript, similar to the existing user-style > functionality? I hate javascript-heavy websites just as much as the > next guy, but it's handy to script stuff on the user-side sometimes > (controlling websites, userscripts, etc.) ELinks has hook support to do this, I don't think this is really a good thing for Vimprobable, really. Unless webkit somehow bloats itself with this level of functionality, then it might make sense to support it. -- Thomas Adam From hannes at yllr.net Wed Jan 26 17:30:26 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Wed, 26 Jan 2011 18:30:26 +0100 Subject: [Vimprobable-users] Disable CSS stylesheets on-the-fly In-Reply-To: <20110125224302.GA4557@msi.domain.invaliddomain.invalid> References: <20110125224302.GA4557@msi.domain.invaliddomain.invalid> Message-ID: <20110126183026.79a2f76f@workstation> Hi! Thayer Williams wrote: > I just recently started using Vimprobable and I'm trying to figure > out a way to disable embedded stylesheets on-the-fly. Vimperator > accomplishes this with :set invum, which calls some internal Firefox > function. I've done some preliminary research into Webkit, though I > haven't yet determined whether it's possible to do this with an > internal function call. > > Google Chrome doesn't offer this ability, but it appears that Safari > does (via the developer mode/settings). Also, there are javascript > bookmarklets[1] in the wild which accomplish nearly the same thing, > but I don't see a clean way of implementing it into vimprobable and > frankly, I'd rather steer clear of javascript hacks entirely. Are you the same person inquiring about "bookmarklets" on IRC? I thought the final conclusion was that they work fine in Vimprobable. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From alkim1234 at gmail.com Wed Jan 26 17:49:57 2011 From: alkim1234 at gmail.com (alkim1234 at gmail.com) Date: Wed, 26 Jan 2011 09:49:57 -0800 Subject: [Vimprobable-users] [PATCH 00/13] New Way to Handle Hinting In-Reply-To: <20110124203738.1cf04d88@laptop2.lan.localhost> References: <1295005150-16318-1-git-send-email-alkim1234@gmail.com> <20110115171002.0135aeda@laptop2.lan.localhost> <20110121061227.GG28375@elements.hsd1.ca.comcast.net> <20110124203738.1cf04d88@laptop2.lan.localhost> Message-ID: <20110126174957.GA20164@elements.hsd1.ca.comcast.net> Hi, > I agree with your sentiments that the indicator in the input line > should be the same key triggering this. I also agree that since f and F > will still be there, it's not a matter of life or death. That said, is > there any reason speaking against simple characters like "." and ","? > "." activates link hinting in Elinks, for example. "," could be used to > activate hinting to open links in a new window. No reason other than my forgetting that the '.' and ',' chars were free. Good call. > To elaborate: I'm not claiming this is handled very well in the browser > right now. It's just that I see the potential to make it much better > with your approach, which is the reason why I keep coming back to this > point. > > I agree that backspace should always be handled by the input box. > Removal of the starting character of the hinting mode should drop the > browser back to normal mode. > > In addition, some other key (which is not required in the input box) > should trigger the removal of the last number entered. I'm not sure how > this could be done, though, as the inputbox has got focus and your way > of handling this doesn't rely on keypress events anymore. I'm sure it's > possible, though. > > I don't care much in what way you get this functionality across. I > don't mind some history through incremental patchsets, but you're also > welcome to re-do the existing series. I'd even be fine with a simple > patchfile you send in addition. Whatever suits you - I'm sure I will be > able to handle it. Awesome, I'll post these patches probably sometime next week. Albert Kim From alkim1234 at gmail.com Wed Jan 26 17:52:49 2011 From: alkim1234 at gmail.com (alkim1234 at gmail.com) Date: Wed, 26 Jan 2011 09:52:49 -0800 Subject: [Vimprobable-users] Small Escape Patch In-Reply-To: <20110121053651.GA28375@elements.hsd1.ca.comcast.net> References: <20110111092633.GA20305@elements.hsd1.ca.comcast.net> <20110115164600.10380ed0@laptop2.lan.localhost> <20110115160704.GA2161@debian> <20110121053651.GA28375@elements.hsd1.ca.comcast.net> Message-ID: <20110126175148.GB20164@elements.hsd1.ca.comcast.net> Can I get a sense for whether this patch will be merged into the git repo? And, if so when? On Thu, Jan 20, 2011 at 09:36:51PM -0800, alkim1234 at gmail.com wrote: > On Sat, Jan 15, 2011 at 04:07:06PM +0000, Thomas Adam wrote: > > On Sat, Jan 15, 2011 at 04:46:00PM +0100, Hannes Sch??ller wrote: > > > Hi! > > > > > > alkim1234 at gmail.com wrote: > > > > This is a small patch provides the macro IS_ESCAPE to check whether a > > > > GdkEventKey should be considered as an escape event. This patch also > > > > adds as an escape event. > > > > > > What's the rationale behind adding C-[ as escape key in the default > > > configuration? I'm not against it per se, just want to know the reason. > > > > In vim, by default, C-[ also sends escape. > > > > But we do need to be careful here, I think. I mean, this *isn't* Vim, it's > > *like* Vim, but I am dubious also by setting an adhoc preference as to which > > parts of Vim we're copying or not. Especially in terms of bloating out the > > code each time. > > Actually, it's pretty standard for C-[ to send the escape signal. Most terminal > emulators support it and vimperator also supports it. > > While I agree with the sentiment that code bloating is bad, I find that this is > a rather small change, and a lot of my friends and I always use C-[ to escape > out of a mode in vim and vimperator. From thayerwilliams at gmail.com Wed Jan 26 17:53:49 2011 From: thayerwilliams at gmail.com (Thayer Williams) Date: Wed, 26 Jan 2011 09:53:49 -0800 Subject: [Vimprobable-users] Disable CSS stylesheets on-the-fly In-Reply-To: <20110126183026.79a2f76f@workstation> References: <20110125224302.GA4557@msi.domain.invaliddomain.invalid> <20110126183026.79a2f76f@workstation> Message-ID: <20110126175349.GB4557@msi.domain.invaliddomain.invalid> On Jan 26, 2011 at 09:30 AM, Hannes Sch?ller wrote: > Hi! > > Thayer Williams wrote: > > I just recently started using Vimprobable and I'm trying to figure > > out a way to disable embedded stylesheets on-the-fly. Vimperator > > accomplishes this with :set invum, which calls some internal Firefox > > function. I've done some preliminary research into Webkit, though I > > haven't yet determined whether it's possible to do this with an > > internal function call. > > > > Google Chrome doesn't offer this ability, but it appears that Safari > > does (via the developer mode/settings). Also, there are javascript > > bookmarklets[1] in the wild which accomplish nearly the same thing, > > but I don't see a clean way of implementing it into vimprobable and > > frankly, I'd rather steer clear of javascript hacks entirely. > > Are you the same person inquiring about "bookmarklets" on IRC? I > thought the final conclusion was that they work fine in Vimprobable. No, I'm not, but I have been trying to launch javascript functions from a keypress (similar to bookmarklet actions) and so far I'm not having any luck. I can use :javascript of course, but I can't figure out a way to automate the afterwards. Currently I have to press enter after pressing the :javascript bind. Any advice? Thanks...and thanks for Vimprobable. This truly is a fantastic browser. Cheers From hannes at yllr.net Wed Jan 26 18:01:13 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Wed, 26 Jan 2011 19:01:13 +0100 Subject: [Vimprobable-users] Small Escape Patch In-Reply-To: <20110126175148.GB20164@elements.hsd1.ca.comcast.net> References: <20110111092633.GA20305@elements.hsd1.ca.comcast.net> <20110115164600.10380ed0@laptop2.lan.localhost> <20110115160704.GA2161@debian> <20110121053651.GA28375@elements.hsd1.ca.comcast.net> <20110126175148.GB20164@elements.hsd1.ca.comcast.net> Message-ID: <20110126190113.26fe868b@workstation> alkim1234 at gmail.com wrote: > Can I get a sense for whether this patch will be merged into the git > repo? And, if so when? As it's quite small, I'm ok with this patch. I will merge it, but for my next push, I've been meaning to wait for your bigger hinting patch to be finalised. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From alkim1234 at gmail.com Wed Jan 26 18:05:53 2011 From: alkim1234 at gmail.com (alkim1234 at gmail.com) Date: Wed, 26 Jan 2011 10:05:53 -0800 Subject: [Vimprobable-users] Small Escape Patch In-Reply-To: <20110126190113.26fe868b@workstation> References: <20110111092633.GA20305@elements.hsd1.ca.comcast.net> <20110115164600.10380ed0@laptop2.lan.localhost> <20110115160704.GA2161@debian> <20110121053651.GA28375@elements.hsd1.ca.comcast.net> <20110126175148.GB20164@elements.hsd1.ca.comcast.net> <20110126190113.26fe868b@workstation> Message-ID: <20110126180553.GA20439@elements.hsd1.ca.comcast.net> On Wed, Jan 26, 2011 at 07:01:13PM +0100, Hannes Sch?ller wrote: > alkim1234 at gmail.com wrote: > > Can I get a sense for whether this patch will be merged into the git > > repo? And, if so when? > > As it's quite small, I'm ok with this patch. I will merge it, but for > my next push, I've been meaning to wait for your bigger hinting patch > to be finalised. Awesome. Will do. From ruskie at codemages.net Wed Jan 26 18:07:55 2011 From: ruskie at codemages.net (=?UTF-8?Q?Andra=C5=BE_'ruskie'_Levstik?=) Date: Wed, 26 Jan 2011 19:07:55 +0100 (CET) Subject: [Vimprobable-users] Disable CSS stylesheets on-the-fly In-Reply-To: <20110126175349.GB4557@msi.domain.invaliddomain.invalid> References: <20110125224302.GA4557@msi.domain.invaliddomain.invalid> <20110126183026.79a2f76f@workstation> <20110126175349.GB4557@msi.domain.invaliddomain.invalid> Message-ID: :2011-01-26T09:53:Thayer Williams: > > > > Are you the same person inquiring about "bookmarklets" on IRC? I > > thought the final conclusion was that they work fine in Vimprobable. That would be me ;) > No, I'm not, but I have been trying to launch javascript functions from a > keypress (similar to bookmarklet actions) and so far I'm not having any luck. > > I can use :javascript of course, but I can't figure out a way to automate the > afterwards. Currently I have to press enter after pressing the > :javascript bind. > > Any advice? Thanks...and thanks for Vimprobable. This truly is a fantastic > browser. Here's what I do(vimprobable2). in config.h I add(for example) into Command commands[COMMANDSIZE] = {: { "lolrand", script, { .s = "(function() { location = location.protocol + '//' + document.domain + '/?random' ; })()"}}, Then rebuild and I have a new command lolrand... then I can bind that to any key I want(or just even leave it like that). I haven't tried keybinding using map a javascript whatever but that's mostly because I don't have anything that I want bound in such a way so far. Hope that helps. -- Andra? 'ruskie' Levstik Source Mage GNU/Linux Games/Xorg grimoire guru Re-Alpine Coordinator http://sourceforge.net/projects/re-alpine/ Geek/Hacker/Tinker Quis custodiet ipsos custodes? From alkim1234 at gmail.com Wed Jan 26 18:24:49 2011 From: alkim1234 at gmail.com (alkim1234 at gmail.com) Date: Wed, 26 Jan 2011 10:24:49 -0800 Subject: [Vimprobable-users] Disable CSS stylesheets on-the-fly In-Reply-To: References: <20110125224302.GA4557@msi.domain.invaliddomain.invalid> <20110126183026.79a2f76f@workstation> <20110126175349.GB4557@msi.domain.invaliddomain.invalid> Message-ID: <20110126182449.GA20491@elements.hsd1.ca.comcast.net> This is a bit off topic, but regarding this: > in config.h I add(for example) into Command commands[COMMANDSIZE] = {: > { "lolrand", script, { .s = "(function() { location = location.protocol + '//' + document.domain + '/?random' ; })()"}}, As per Thomas Adam's suggestion, I had script just free the strings of the arg passed into it, so that it's not forgotten in in other places in the code. I do this simply by: if (arg->s) g_free(arg->s); However, if people add code like above where arg->s is on the stack, the code is likely to segfault. Any suggestions on how to get around this? Albert Kim From hannes at yllr.net Wed Jan 26 18:59:12 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Wed, 26 Jan 2011 19:59:12 +0100 Subject: [Vimprobable-users] Disable CSS stylesheets on-the-fly In-Reply-To: <20110126182449.GA20491@elements.hsd1.ca.comcast.net> References: <20110125224302.GA4557@msi.domain.invaliddomain.invalid> <20110126183026.79a2f76f@workstation> <20110126175349.GB4557@msi.domain.invaliddomain.invalid> <20110126182449.GA20491@elements.hsd1.ca.comcast.net> Message-ID: <20110126195912.5a1ab9ee@workstation> alkim1234 at gmail.com wrote: > This is a bit off topic, but regarding this: > > > in config.h I add(for example) into Command commands[COMMANDSIZE] = > > {: { "lolrand", > > script, { .s = "(function() { location = > > location.protocol + '//' + document.domain + > > '/?random' ; })()"}}, > > As per Thomas Adam's suggestion, I had script just free the strings > of the arg passed into it, so that it's not forgotten in in other > places in the code. I do this simply by: > > if (arg->s) > g_free(arg->s); > > However, if people add code like above where arg->s is on the stack, > the code is likely to segfault. Any suggestions on how to get around > this? I don't think there is a perfect solution there. Maybe it's simply not a good idea to handle memory allocation / freeing asymmetricly. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From hannes at yllr.net Wed Jan 26 19:02:29 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Wed, 26 Jan 2011 20:02:29 +0100 Subject: [Vimprobable-users] Disable CSS stylesheets on-the-fly In-Reply-To: <20110126175349.GB4557@msi.domain.invaliddomain.invalid> References: <20110125224302.GA4557@msi.domain.invaliddomain.invalid> <20110126183026.79a2f76f@workstation> <20110126175349.GB4557@msi.domain.invaliddomain.invalid> Message-ID: <20110126200229.007bc47d@workstation> Hi! Thayer Williams wrote: > On Jan 26, 2011 at 09:30 AM, Hannes Sch?ller wrote: > > Thayer Williams wrote: > > > I just recently started using Vimprobable and I'm trying to figure > > > out a way to disable embedded stylesheets on-the-fly. Vimperator > > > accomplishes this with :set invum, which calls some internal > > > Firefox function. I've done some preliminary research into > > > Webkit, though I haven't yet determined whether it's possible to > > > do this with an internal function call. > > > > > > Google Chrome doesn't offer this ability, but it appears that > > > Safari does (via the developer mode/settings). Also, there are > > > javascript bookmarklets[1] in the wild which accomplish nearly > > > the same thing, but I don't see a clean way of implementing it > > > into vimprobable and frankly, I'd rather steer clear of > > > javascript hacks entirely. > > > > Are you the same person inquiring about "bookmarklets" on IRC? I > > thought the final conclusion was that they work fine in Vimprobable. > > No, I'm not, but I have been trying to launch javascript functions > from a keypress (similar to bookmarklet actions) and so far I'm not > having any luck. Oh, sorry. It's just that I heard the term "bookmarklets" for the first time last night on IRC, and then it turned up here again. So I figured it would be too much of a coincidence ;) > I can use :javascript of course, but I can't figure out a way to > automate the afterwards. Currently I have to press enter after > pressing the :javascript bind. I see what you mean, the "code submission" is missing if you're using the regular key mappings. You can see the Andra?' example - that will work, and after making that definition, you can bind a key to that new command. It should work, then. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From thomas at xteddy.org Wed Jan 26 19:45:16 2011 From: thomas at xteddy.org (Thomas Adam) Date: Wed, 26 Jan 2011 19:45:16 +0000 Subject: [Vimprobable-users] Disable CSS stylesheets on-the-fly In-Reply-To: <20110126182449.GA20491@elements.hsd1.ca.comcast.net> References: <20110125224302.GA4557@msi.domain.invaliddomain.invalid> <20110126183026.79a2f76f@workstation> <20110126175349.GB4557@msi.domain.invaliddomain.invalid> <20110126182449.GA20491@elements.hsd1.ca.comcast.net> Message-ID: <20110126194514.GA2385@debian> On Wed, Jan 26, 2011 at 10:24:49AM -0800, alkim1234 at gmail.com wrote: > This is a bit off topic, but regarding this: > > > in config.h I add(for example) into Command commands[COMMANDSIZE] = {: > > { "lolrand", script, { .s = "(function() { location = location.protocol + '//' + document.domain + '/?random' ; })()"}}, > > As per Thomas Adam's suggestion, I had script just free the strings of the arg > passed into it, so that it's not forgotten in in other places in the code. I do > this simply by: > > if (arg->s) > g_free(arg->s); > > However, if people add code like above where arg->s is on the stack, the code is > likely to segfault. Any suggestions on how to get around this? See patch attached. -- Thomas Adam -- "It was the cruelest game I've ever played and it's played inside my head." -- "Hush The Warmth", Gorky's Zygotic Mynci. From thomas at xteddy.org Wed Jan 26 19:48:04 2011 From: thomas at xteddy.org (Thomas Adam) Date: Wed, 26 Jan 2011 19:48:04 +0000 Subject: [Vimprobable-users] [PATCH 1/1] Make general arguments to commands free-by-callee Message-ID: <20110126194754.GA5164@debian> Because most Vimprobable commands now free from the place they're called, ensure commands can still be allocated "on the stack" (that is statically from config.h) by free()ing those if they haven't been free()d already. --- main.c | 38 +++++++++++++++++++++++++++++--------- 1 files changed, 29 insertions(+), 9 deletions(-) diff --git a/main.c b/main.c index 95ad0cd..1b9b806 100644 --- a/main.c +++ b/main.c @@ -193,7 +193,7 @@ ascii_bar(int total, int state, char *string) { void webview_load_committed_cb(WebKitWebView *webview, WebKitWebFrame *frame, gpointer user_data) { - Arg a = { .i = Silent, .s = JS_SETUP_HINTS }; + Arg a = { .i = Silent, .s = g_strdup(JS_SETUP_HINTS) }; const char *uri = webkit_web_view_get_uri(webview); update_url(uri); @@ -202,7 +202,7 @@ webview_load_committed_cb(WebKitWebView *webview, WebKitWebFrame *frame, gpointe void webview_load_finished_cb(WebKitWebView *webview, WebKitWebFrame *frame, gpointer user_data) { - Arg a = { .i = Silent, .s = JS_SETUP_INPUT_FOCUS }; + Arg a = { .i = Silent, .s = g_strdup(JS_SETUP_INPUT_FOCUS) }; if (HISTORY_MAX_ENTRIES > 0) history(); @@ -364,7 +364,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { case ModeInsert: if (CLEAN(event->state) == 0 && event->keyval == GDK_Escape) { a.i = Silent; - a.s = "vimprobable_clearfocus()"; + a.s = g_strdup("vimprobable_clearfocus()"); script(&a); a.i = ModeNormal; return set(&a); @@ -383,7 +383,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { case ModeHints: if (CLEAN(event->state) == 0 && event->keyval == GDK_Escape) { a.i = Silent; - a.s = "vimprobable_clear()"; + a.s = g_strdup("vimprobable_clear()"); script(&a); a.i = ModeNormal; count = 0; @@ -437,7 +437,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { memset(inputKey, 0, 5); count = 0; a.i = Silent; - a.s = "vimprobable_cleanup()"; + a.s = g_strdup("vimprobable_cleanup()"); script(&a); a.s = g_strconcat("vimprobable_show_hints('", inputBuffer, "')", NULL); a.i = Silent; @@ -470,7 +470,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { count = 0; memset(inputBuffer, 0, 65); a.i = Silent; - a.s = "vimprobable_cleanup()"; + a.s = g_strdup("vimprobable_cleanup()"); script(&a); a.s = g_strconcat("vimprobable_show_hints()", NULL); a.i = Silent; @@ -478,7 +478,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { update_state(); } else if (strlen(inputBuffer) > 0) { a.i = Silent; - a.s = "vimprobable_cleanup()"; + a.s = g_strdup("vimprobable_cleanup()"); script(&a); /* check how many bytes the last character uses */ for (count = 0; count < 64; count++) { @@ -564,6 +564,7 @@ inputbox_activate_cb(GtkEntry *entry, gpointer user_data) { int i; size_t len; gboolean success = FALSE, forward = FALSE, found = FALSE; + gboolean did_malloc = FALSE; a.i = HideCompletion; complete(&a); @@ -578,8 +579,22 @@ inputbox_activate_cb(GtkEntry *entry, gpointer user_data) { if (length >= len && !strncmp(&text[1], commands[i].cmd, len) && (text[len + 1] == ' ' || !text[len + 1])) { found = TRUE; a.i = commands[i].arg.i; - a.s = length > len + 2 ? &text[len + 2] : commands[i].arg.s; + + if (length > len + 2) { + a.s = &text[len + 2]; + did_malloc = FALSE; + } else { + a.s = g_strdup(commands[i].arg.s ? commands[i].arg.s : ""); + did_malloc = TRUE; + } success = commands[i].func(&a); + + /* TA: FIXME - likely other commands here won't have free()d. + * Maybe they should. + */ + if (did_malloc && !a.s) + g_free(a.s); + break; } } @@ -1264,7 +1279,7 @@ set(const Arg *arg) { memset(followTarget, 0, 8); strncpy(followTarget, arg->s, 8); a.i = Silent; - a.s = "vimprobable_show_hints()"; + a.s = strdup("vimprobable_show_hints()"); script(&a); break; default: @@ -1378,6 +1393,11 @@ script(const Arg *arg) { } } g_free(value); + + /* free() the command string given. */ + if (arg->s) + g_free(arg->s); + return TRUE; } 1.7.2.3 From thomas at xteddy.org Wed Jan 26 19:52:27 2011 From: thomas at xteddy.org (Thomas Adam) Date: Wed, 26 Jan 2011 19:52:27 +0000 Subject: [Vimprobable-users] Disable CSS stylesheets on-the-fly In-Reply-To: <20110126195912.5a1ab9ee@workstation> References: <20110125224302.GA4557@msi.domain.invaliddomain.invalid> <20110126183026.79a2f76f@workstation> <20110126175349.GB4557@msi.domain.invaliddomain.invalid> <20110126182449.GA20491@elements.hsd1.ca.comcast.net> <20110126195912.5a1ab9ee@workstation> Message-ID: <20110126195226.GB2385@debian> On Wed, Jan 26, 2011 at 07:59:12PM +0100, Hannes Sch??ller wrote: > alkim1234 at gmail.com wrote: > > This is a bit off topic, but regarding this: > > > > > in config.h I add(for example) into Command commands[COMMANDSIZE] = > > > {: { "lolrand", > > > script, { .s = "(function() { location = > > > location.protocol + '//' + document.domain + > > > '/?random' ; })()"}}, > > > > As per Thomas Adam's suggestion, I had script just free the strings > > of the arg passed into it, so that it's not forgotten in in other > > places in the code. I do this simply by: > > > > if (arg->s) > > g_free(arg->s); > > > > However, if people add code like above where arg->s is on the stack, > > the code is likely to segfault. Any suggestions on how to get around > > this? > > I don't think there is a perfect solution there. Maybe it's simply not > a good idea to handle memory allocation / freeing asymmetricly. Heh. Before this patch, and others in the past where I've done this, there were too many instances of g_strconcat(), g_strdup() and other variants which were assiged to any old a.s or a->s and then never free()d again. The lesser of two evils is to pick one. At the time, free()ing from the place the thing was used in was easier than to keep adding free() or g_free() time and again where it was used. The nice thing about this patch, and others is that you then get the clean-ups from the original malloc()ed memory for, umm, free. :) -- Thomas Adam -- "It was the cruelest game I've ever played and it's played inside my head." -- "Hush The Warmth", Gorky's Zygotic Mynci. From thomas at xteddy.org Wed Jan 26 21:25:32 2011 From: thomas at xteddy.org (Thomas Adam) Date: Wed, 26 Jan 2011 21:25:32 +0000 Subject: [Vimprobable-users] [PATCH v2 1/1] Make general arguments to commands free-by-callee Message-ID: <20110126212524.GA5875@debian> Because most Vimprobable commands now free from the place they're called, ensure commands can still be allocated "on the stack" (that is statically from config.h) by free()ing those if they haven't been free()d already. --- Woops -- sorry, Hannes. Mistook a strdup for a g_strdup -- so corrected that oversight. Glib recommends marrying up g_foo* with g_bar* equivalents. Likely this won't cause a problem, but I do like to try and be thorough. :) main.c | 38 +++++++++++++++++++++++++++++--------- 1 files changed, 29 insertions(+), 9 deletions(-) diff --git a/main.c b/main.c index 95ad0cd..3b0db82 100644 --- a/main.c +++ b/main.c @@ -193,7 +193,7 @@ ascii_bar(int total, int state, char *string) { void webview_load_committed_cb(WebKitWebView *webview, WebKitWebFrame *frame, gpointer user_data) { - Arg a = { .i = Silent, .s = JS_SETUP_HINTS }; + Arg a = { .i = Silent, .s = g_strdup(JS_SETUP_HINTS) }; const char *uri = webkit_web_view_get_uri(webview); update_url(uri); @@ -202,7 +202,7 @@ webview_load_committed_cb(WebKitWebView *webview, WebKitWebFrame *frame, gpointe void webview_load_finished_cb(WebKitWebView *webview, WebKitWebFrame *frame, gpointer user_data) { - Arg a = { .i = Silent, .s = JS_SETUP_INPUT_FOCUS }; + Arg a = { .i = Silent, .s = g_strdup(JS_SETUP_INPUT_FOCUS) }; if (HISTORY_MAX_ENTRIES > 0) history(); @@ -364,7 +364,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { case ModeInsert: if (CLEAN(event->state) == 0 && event->keyval == GDK_Escape) { a.i = Silent; - a.s = "vimprobable_clearfocus()"; + a.s = g_strdup("vimprobable_clearfocus()"); script(&a); a.i = ModeNormal; return set(&a); @@ -383,7 +383,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { case ModeHints: if (CLEAN(event->state) == 0 && event->keyval == GDK_Escape) { a.i = Silent; - a.s = "vimprobable_clear()"; + a.s = g_strdup("vimprobable_clear()"); script(&a); a.i = ModeNormal; count = 0; @@ -437,7 +437,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { memset(inputKey, 0, 5); count = 0; a.i = Silent; - a.s = "vimprobable_cleanup()"; + a.s = g_strdup("vimprobable_cleanup()"); script(&a); a.s = g_strconcat("vimprobable_show_hints('", inputBuffer, "')", NULL); a.i = Silent; @@ -470,7 +470,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { count = 0; memset(inputBuffer, 0, 65); a.i = Silent; - a.s = "vimprobable_cleanup()"; + a.s = g_strdup("vimprobable_cleanup()"); script(&a); a.s = g_strconcat("vimprobable_show_hints()", NULL); a.i = Silent; @@ -478,7 +478,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { update_state(); } else if (strlen(inputBuffer) > 0) { a.i = Silent; - a.s = "vimprobable_cleanup()"; + a.s = g_strdup("vimprobable_cleanup()"); script(&a); /* check how many bytes the last character uses */ for (count = 0; count < 64; count++) { @@ -564,6 +564,7 @@ inputbox_activate_cb(GtkEntry *entry, gpointer user_data) { int i; size_t len; gboolean success = FALSE, forward = FALSE, found = FALSE; + gboolean did_malloc = FALSE; a.i = HideCompletion; complete(&a); @@ -578,8 +579,22 @@ inputbox_activate_cb(GtkEntry *entry, gpointer user_data) { if (length >= len && !strncmp(&text[1], commands[i].cmd, len) && (text[len + 1] == ' ' || !text[len + 1])) { found = TRUE; a.i = commands[i].arg.i; - a.s = length > len + 2 ? &text[len + 2] : commands[i].arg.s; + + if (length > len + 2) { + a.s = &text[len + 2]; + did_malloc = FALSE; + } else { + a.s = g_strdup(commands[i].arg.s ? commands[i].arg.s : ""); + did_malloc = TRUE; + } success = commands[i].func(&a); + + /* TA: FIXME - likely other commands here won't have free()d. + * Maybe they should. + */ + if (did_malloc && !a.s) + g_free(a.s); + break; } } @@ -1264,7 +1279,7 @@ set(const Arg *arg) { memset(followTarget, 0, 8); strncpy(followTarget, arg->s, 8); a.i = Silent; - a.s = "vimprobable_show_hints()"; + a.s = g_strdup("vimprobable_show_hints()"); script(&a); break; default: @@ -1378,6 +1393,11 @@ script(const Arg *arg) { } } g_free(value); + + /* free() the command string given. */ + if (arg->s) + g_free(arg->s); + return TRUE; } -- 1.7.2.3 From thayerwilliams at gmail.com Thu Jan 27 03:48:41 2011 From: thayerwilliams at gmail.com (Thayer Williams) Date: Wed, 26 Jan 2011 19:48:41 -0800 Subject: [Vimprobable-users] Disable CSS stylesheets on-the-fly In-Reply-To: References: <20110125224302.GA4557@msi.domain.invaliddomain.invalid> <20110126183026.79a2f76f@workstation> <20110126175349.GB4557@msi.domain.invaliddomain.invalid> Message-ID: <20110127034841.GC4557@msi.domain.invaliddomain.invalid> On Jan 26, 2011 at 10:07 AM, Andra? 'ruskie' Levstik wrote: > :2011-01-26T09:53:Thayer Williams: > > > No, I'm not, but I have been trying to launch javascript functions from a > > keypress (similar to bookmarklet actions) and so far I'm not having any luck. > > > > I can use :javascript of course, but I can't figure out a way to automate the > > afterwards. Currently I have to press enter after pressing the > > :javascript bind. > > > > Any advice? Thanks...and thanks for Vimprobable. This truly is a fantastic > > browser. > > Here's what I do(vimprobable2). > > in config.h I add(for example) into Command commands[COMMANDSIZE] = {: > { "lolrand", script, { .s = "(function() { location = location.protocol + '//' + document.domain + '/?random' ; })()"}}, > > Then rebuild and I have a new command lolrand... then I can bind that to > any key I want(or just even leave it like that). I haven't tried > keybinding using map a javascript whatever but that's mostly because I > don't have anything that I want bound in such a way so far. > > Hope that helps. This sounds great! Would you mind sending me (or posting) a copy of your config.h and keymap.h? In keymap.h, when I try inserting the new function name in the function column, or as an argument to the 'script' function, the compile errors with: error: ?disablecss? undeclared here (not in a function) If I try to run the function directly from command mode, I get "SyntaxError: Parse error". I'm sure I'm just doing something silly (being a non-programmer and all). Cheers From thomas at xteddy.org Thu Jan 27 06:26:20 2011 From: thomas at xteddy.org (Thomas Adam) Date: Thu, 27 Jan 2011 06:26:20 +0000 Subject: [Vimprobable-users] Disable CSS stylesheets on-the-fly In-Reply-To: <20110127034841.GC4557@msi.domain.invaliddomain.invalid> References: <20110125224302.GA4557@msi.domain.invaliddomain.invalid> <20110126183026.79a2f76f@workstation> <20110126175349.GB4557@msi.domain.invaliddomain.invalid> <20110127034841.GC4557@msi.domain.invaliddomain.invalid> Message-ID: <20110127062617.GA2209@debian> On Wed, Jan 26, 2011 at 07:48:41PM -0800, Thayer Williams wrote: > On Jan 26, 2011 at 10:07 AM, Andra?? 'ruskie' Levstik wrote: > > :2011-01-26T09:53:Thayer Williams: > > > > > No, I'm not, but I have been trying to launch javascript functions from a > > > keypress (similar to bookmarklet actions) and so far I'm not having any luck. > > > > > > I can use :javascript of course, but I can't figure out a way to automate the > > > afterwards. Currently I have to press enter after pressing the > > > :javascript bind. > > > > > > Any advice? Thanks...and thanks for Vimprobable. This truly is a fantastic > > > browser. > > > > Here's what I do(vimprobable2). > > > > in config.h I add(for example) into Command commands[COMMANDSIZE] = {: > > { "lolrand", script, { .s = "(function() { location = location.protocol + '//' + document.domain + '/?random' ; })()"}}, > > > > Then rebuild and I have a new command lolrand... then I can bind that to > > any key I want(or just even leave it like that). I haven't tried > > keybinding using map a javascript whatever but that's mostly because I > > don't have anything that I want bound in such a way so far. > > > > Hope that helps. > > This sounds great! Would you mind sending me (or posting) a copy of your > config.h and keymap.h? > > In keymap.h, when I try inserting the new function name in the function > column, or as an argument to the 'script' function, the compile errors with: > > error: ???disablecss??? undeclared here (not in a function) No, it's meant to go in config.h in the commands[] array -- around line 133 or so. As for disablecss being undeclared, that sounds like some left over innards from something else? > If I try to run the function directly from command mode, I get "SyntaxError: > Parse error". I'm sure I'm just doing something silly (being a non-programmer > and all). See above. -- Thomas Adam -- "It was the cruelest game I've ever played and it's played inside my head." -- "Hush The Warmth", Gorky's Zygotic Mynci. From ruskie at codemages.net Thu Jan 27 06:40:03 2011 From: ruskie at codemages.net (=?UTF-8?Q?Andra=C5=BE_'ruskie'_Levstik?=) Date: Thu, 27 Jan 2011 07:40:03 +0100 (CET) Subject: [Vimprobable-users] Disable CSS stylesheets on-the-fly In-Reply-To: <20110127034841.GC4557@msi.domain.invaliddomain.invalid> References: <20110125224302.GA4557@msi.domain.invaliddomain.invalid> <20110126183026.79a2f76f@workstation> <20110126175349.GB4557@msi.domain.invaliddomain.invalid> <20110127034841.GC4557@msi.domain.invaliddomain.invalid> Message-ID: :2011-01-26T19:48:Thayer Williams: > This sounds great! Would you mind sending me (or posting) a copy of your > config.h and keymap.h? Posting my entire config repo(the config.h is there): http://ruskie.codemages.net/viewgit/?a=summary&p=vimprobable > In keymap.h, when I try inserting the new function name in the function > column, or as an argument to the 'script' function, the compile errors with: Note I'm using vimprobable2 which has :map so can map keys on the fly. Hope it helps. -- Andra? 'ruskie' Levstik Source Mage GNU/Linux Games/Xorg grimoire guru Re-Alpine Coordinator http://sourceforge.net/projects/re-alpine/ Geek/Hacker/Tinker I may not agree with what you say, but I'll defend your right to say it. From thayerwilliams at gmail.com Thu Jan 27 16:19:47 2011 From: thayerwilliams at gmail.com (Thayer Williams) Date: Thu, 27 Jan 2011 08:19:47 -0800 Subject: [Vimprobable-users] Disable CSS stylesheets on-the-fly In-Reply-To: <20110127062617.GA2209@debian> References: <20110125224302.GA4557@msi.domain.invaliddomain.invalid> <20110126183026.79a2f76f@workstation> <20110126175349.GB4557@msi.domain.invaliddomain.invalid> <20110127034841.GC4557@msi.domain.invaliddomain.invalid> <20110127062617.GA2209@debian> Message-ID: <20110127161947.GD4557@msi.domain.invaliddomain.invalid> On Jan 26, 2011 at 10:26 PM, Thomas Adam wrote: > On Wed, Jan 26, 2011 at 07:48:41PM -0800, Thayer Williams wrote: > > On Jan 26, 2011 at 10:07 AM, Andra?? 'ruskie' Levstik wrote: > > > > > > Here's what I do(vimprobable2). > > > > > > in config.h I add(for example) into Command commands[COMMANDSIZE] = {: > > > { "lolrand", script, { .s = "(function() { location = location.protocol + '//' + document.domain + '/?random' ; })()"}}, > > > > > > Then rebuild and I have a new command lolrand... then I can bind that to > > > any key I want(or just even leave it like that). I haven't tried > > > keybinding using map a javascript whatever but that's mostly because I > > > don't have anything that I want bound in such a way so far. > > > > > > Hope that helps. > > > > This sounds great! Would you mind sending me (or posting) a copy of your > > config.h and keymap.h? > > > > In keymap.h, when I try inserting the new function name in the function > > column, or as an argument to the 'script' function, the compile errors with: > > > > error: ???disablecss??? undeclared here (not in a function) > > No, it's meant to go in config.h in the commands[] array -- around line 133 > or so. I had that much right, but the problem occurs when I then try to add a key binding for the new function to keymap.h. I probably just have the syntax wrong, so far I've tried: { 0, 0, GDK_c, disablecss, {} }, { 0, 0, GDK_c, disablecss, {0} }, { 0, 0, GDK_c, script, {disablecss} }, All of these result in 'disablecss is undeclared'. It works however if I map it within vimprobablerc, so I'm fine with that: map c disablecss As for the Parse error, I had missed an additional closing bracket when making it self-invoking; upon fixing that it works great. The end result for posterity: { "disablecss", script, { .s = "(function() { for(i = 0; i < document.styleSheets.length; i++) { void(document.styleSheets.item(i).disabled=true); } el = document.getElementsByTagName('*'); for(i = 0; i < el.length; i++) { void(el[i].style.cssText='');}})();" } }, Thanks everybody for your assistance, especially Andra for the examples and configs. Cheers From thomas at xteddy.org Sun Jan 30 02:31:48 2011 From: thomas at xteddy.org (Thomas Adam) Date: Sun, 30 Jan 2011 02:31:48 +0000 Subject: [Vimprobable-users] [PATCH 1/1] Don't segfault overflowing MAX_LIST_SIZE in complete() Message-ID: <20110130023144.GA7226@debian.ttn6tadam> When completing the command list, at the command prompt, ensure we malloc and then realloc by not assuming this list is initially the length of MAX_LIST_SIZE. Instead, calculate the size of the command list at runtime, and use that value to malloc correctly. This doesn't then attempt to overwrite any memory when realloc()ing. This does need a bit of a rethink though. But for now, we should be OK. I'm still concerned that the realloc() parts might cause us problems in the future, but it should be OK for now. --- main.c | 38 +++++++++++++++++++++++++++++--------- 1 files changed, 29 insertions(+), 9 deletions(-) diff --git a/main.c b/main.c index 95ad0cd..63bd719 100644 --- a/main.c +++ b/main.c @@ -753,12 +753,20 @@ complete(const Arg *arg) { GtkWidget *row_eventbox, *el; GtkBox *_table; GdkColor color; - static GtkWidget *table, **widgets, *top_border; - static char **suggestions, *prefix; + static GtkWidget *table, *top_border; + static char *prefix; + static char **suggestions; + static GtkWidget **widgets; static int n = 0, m, current = -1; str = (char*)gtk_entry_get_text(GTK_ENTRY(inputbox)); len = strlen(str); + + /* Get the length of the list of commands for completion. We need this to + * malloc/realloc correctly. + */ + listlen = LENGTH(commands); + if ((len == 0 || str[0] != ':') && arg->i != HideCompletion) return TRUE; if (prefix) { @@ -788,8 +796,8 @@ complete(const Arg *arg) { return TRUE; if (!widgets) { prefix = g_strdup_printf(str); - widgets = malloc(sizeof(GtkWidget*) * MAX_LIST_SIZE); - suggestions = malloc(sizeof(char*) * MAX_LIST_SIZE); + widgets = malloc(sizeof(GtkWidget*) * listlen); + suggestions = malloc(sizeof(char*) * listlen); top_border = gtk_event_box_new(); gtk_widget_set_size_request(GTK_WIDGET(top_border), 0, 1); gdk_color_parse(completioncolor[2], &color); @@ -800,7 +808,6 @@ complete(const Arg *arg) { highlight = len > 1; if (strchr(str, ' ') == NULL) { /* command completion */ - listlen = LENGTH(commands); for (i = 0; i < listlen; i++) { if (commands[i].cmd == NULL) break; @@ -836,7 +843,7 @@ complete(const Arg *arg) { return FALSE; } memset(entry, 0, 512); - suggurls = malloc(sizeof(char*) * MAX_LIST_SIZE); + suggurls = malloc(sizeof(char*) * listlen); if (suggurls == NULL) { return FALSE; } @@ -845,7 +852,6 @@ complete(const Arg *arg) { strncpy(command, (str + 1), spacepos - 1); if (strlen(command) == 3 && strncmp(command, "set", 3) == 0) { /* browser settings */ - listlen = LENGTH(browsersettings); for (i = 0; i < listlen; i++) { if (n < MAX_LIST_SIZE && strstr(browsersettings[i].name, searchfor) != NULL) { /* match */ @@ -896,8 +902,22 @@ complete(const Arg *arg) { entry = NULL; } } - widgets = realloc(widgets, sizeof(GtkWidget*) * n); - suggestions = realloc(suggestions, sizeof(char*) * n); + /* TA: FIXME - this needs rethinking entirely. */ + { + GtkWidget **widgets_temp = realloc(widgets, sizeof(*widgets) * n); + if (widgets_temp == NULL) { + fprintf(stderr, "Couldn't realloc() widgets\n"); + exit(1); + } + widgets = widgets_temp; + + char **suggestions_temp = realloc(suggestions, sizeof(*suggestions) * n); + if (suggestions_temp == NULL) { + fprintf(stderr, "Couldn't realloc() suggestions\n"); + exit(1); + } + suggestions = suggestions_temp; + } if (!n) { gdk_color_parse(completionbgcolor[1], &color); gtk_widget_modify_bg(table, GTK_STATE_NORMAL, &color); 1.7.2.3 From alkim1234 at gmail.com Sun Jan 30 02:30:11 2011 From: alkim1234 at gmail.com (alkim1234 at gmail.com) Date: Sat, 29 Jan 2011 18:30:11 -0800 Subject: [Vimprobable-users] [PATCH v2 1/1] Make general arguments to commands free-by-callee In-Reply-To: <20110126212524.GA5875@debian> References: <20110126212524.GA5875@debian> Message-ID: <20110130023011.GA22142@elements.hsd1.ca.comcast.net> This is fine and actually already included in my patch, when I made script g_free all arg->s. I was actually talking about the strings in config.h. I'm a little more afraid to change these because it will result in breaking a lot of configs if this change goes out. On Wed, Jan 26, 2011 at 09:25:32PM +0000, Thomas Adam wrote: > Because most Vimprobable commands now free from the place they're called, > ensure commands can still be allocated "on the stack" (that is statically > from config.h) by free()ing those if they haven't been free()d already. > --- > Woops -- sorry, Hannes. Mistook a strdup for a g_strdup -- so corrected > that oversight. Glib recommends marrying up g_foo* with g_bar* > equivalents. Likely this won't cause a problem, but I do like to try and > be thorough. :) > > main.c | 38 +++++++++++++++++++++++++++++--------- > 1 files changed, 29 insertions(+), 9 deletions(-) > > diff --git a/main.c b/main.c > index 95ad0cd..3b0db82 100644 > --- a/main.c > +++ b/main.c > @@ -193,7 +193,7 @@ ascii_bar(int total, int state, char *string) { > > void > webview_load_committed_cb(WebKitWebView *webview, WebKitWebFrame *frame, gpointer user_data) { > - Arg a = { .i = Silent, .s = JS_SETUP_HINTS }; > + Arg a = { .i = Silent, .s = g_strdup(JS_SETUP_HINTS) }; > const char *uri = webkit_web_view_get_uri(webview); > > update_url(uri); > @@ -202,7 +202,7 @@ webview_load_committed_cb(WebKitWebView *webview, WebKitWebFrame *frame, gpointe > > void > webview_load_finished_cb(WebKitWebView *webview, WebKitWebFrame *frame, gpointer user_data) { > - Arg a = { .i = Silent, .s = JS_SETUP_INPUT_FOCUS }; > + Arg a = { .i = Silent, .s = g_strdup(JS_SETUP_INPUT_FOCUS) }; > > if (HISTORY_MAX_ENTRIES > 0) > history(); > @@ -364,7 +364,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { > case ModeInsert: > if (CLEAN(event->state) == 0 && event->keyval == GDK_Escape) { > a.i = Silent; > - a.s = "vimprobable_clearfocus()"; > + a.s = g_strdup("vimprobable_clearfocus()"); > script(&a); > a.i = ModeNormal; > return set(&a); > @@ -383,7 +383,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { > case ModeHints: > if (CLEAN(event->state) == 0 && event->keyval == GDK_Escape) { > a.i = Silent; > - a.s = "vimprobable_clear()"; > + a.s = g_strdup("vimprobable_clear()"); > script(&a); > a.i = ModeNormal; > count = 0; > @@ -437,7 +437,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { > memset(inputKey, 0, 5); > count = 0; > a.i = Silent; > - a.s = "vimprobable_cleanup()"; > + a.s = g_strdup("vimprobable_cleanup()"); > script(&a); > a.s = g_strconcat("vimprobable_show_hints('", inputBuffer, "')", NULL); > a.i = Silent; > @@ -470,7 +470,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { > count = 0; > memset(inputBuffer, 0, 65); > a.i = Silent; > - a.s = "vimprobable_cleanup()"; > + a.s = g_strdup("vimprobable_cleanup()"); > script(&a); > a.s = g_strconcat("vimprobable_show_hints()", NULL); > a.i = Silent; > @@ -478,7 +478,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { > update_state(); > } else if (strlen(inputBuffer) > 0) { > a.i = Silent; > - a.s = "vimprobable_cleanup()"; > + a.s = g_strdup("vimprobable_cleanup()"); > script(&a); > /* check how many bytes the last character uses */ > for (count = 0; count < 64; count++) { > @@ -564,6 +564,7 @@ inputbox_activate_cb(GtkEntry *entry, gpointer user_data) { > int i; > size_t len; > gboolean success = FALSE, forward = FALSE, found = FALSE; > + gboolean did_malloc = FALSE; > > a.i = HideCompletion; > complete(&a); > @@ -578,8 +579,22 @@ inputbox_activate_cb(GtkEntry *entry, gpointer user_data) { > if (length >= len && !strncmp(&text[1], commands[i].cmd, len) && (text[len + 1] == ' ' || !text[len + 1])) { > found = TRUE; > a.i = commands[i].arg.i; > - a.s = length > len + 2 ? &text[len + 2] : commands[i].arg.s; > + > + if (length > len + 2) { > + a.s = &text[len + 2]; > + did_malloc = FALSE; > + } else { > + a.s = g_strdup(commands[i].arg.s ? commands[i].arg.s : ""); > + did_malloc = TRUE; > + } > success = commands[i].func(&a); > + > + /* TA: FIXME - likely other commands here won't have free()d. > + * Maybe they should. > + */ > + if (did_malloc && !a.s) > + g_free(a.s); > + > break; > } > } > @@ -1264,7 +1279,7 @@ set(const Arg *arg) { > memset(followTarget, 0, 8); > strncpy(followTarget, arg->s, 8); > a.i = Silent; > - a.s = "vimprobable_show_hints()"; > + a.s = g_strdup("vimprobable_show_hints()"); > script(&a); > break; > default: > @@ -1378,6 +1393,11 @@ script(const Arg *arg) { > } > } > g_free(value); > + > + /* free() the command string given. */ > + if (arg->s) > + g_free(arg->s); > + > return TRUE; > } > > -- > 1.7.2.3 > _______________________________________________ > Vimprobable-users mailing list > Vimprobable-users at vimprobable.org > http://vimprobable.org/mailman/listinfo/vimprobable-users From thomas at xteddy.org Sun Jan 30 02:35:16 2011 From: thomas at xteddy.org (Thomas Adam) Date: Sun, 30 Jan 2011 02:35:16 +0000 Subject: [Vimprobable-users] [PATCH v2 1/1] Make general arguments to commands free-by-callee In-Reply-To: <20110130023011.GA22142@elements.hsd1.ca.comcast.net> References: <20110126212524.GA5875@debian> <20110130023011.GA22142@elements.hsd1.ca.comcast.net> Message-ID: <20110130023516.GB3297@debian.ttn6tadam> On Sat, Jan 29, 2011 at 06:30:11PM -0800, alkim1234 at gmail.com wrote: > This is fine and actually already included in my patch, when I made script > g_free all arg->s. I was actually talking about the strings in config.h. I'm a That part might be, but it still won't have handled having .s entries in config.h where the functions themselves assume they're pointers to malloc()d memory areas, rather than declared on the stack. > little more afraid to change these because it will result in breaking a lot of > configs if this change goes out. Specifically? What are you afraid of which this patch potentially won't cater for anyway? Can you also try and not top-post? Thanks -- Thomas Adam -- "It was the cruelest game I've ever played and it's played inside my head." -- "Hush The Warmth", Gorky's Zygotic Mynci. From alkim1234 at gmail.com Sun Jan 30 03:17:20 2011 From: alkim1234 at gmail.com (alkim1234 at gmail.com) Date: Sat, 29 Jan 2011 19:17:20 -0800 Subject: [Vimprobable-users] [PATCH v2 1/1] Make general arguments to commands free-by-callee In-Reply-To: <20110130023516.GB3297@debian.ttn6tadam> References: <20110126212524.GA5875@debian> <20110130023011.GA22142@elements.hsd1.ca.comcast.net> <20110130023516.GB3297@debian.ttn6tadam> Message-ID: <20110130031720.GA22328@elements.hsd1.ca.comcast.net> On Sun, Jan 30, 2011 at 02:35:16AM +0000, Thomas Adam wrote: > On Sat, Jan 29, 2011 at 06:30:11PM -0800, alkim1234 at gmail.com wrote: > > This is fine and actually already included in my patch, when I made script > > g_free all arg->s. I was actually talking about the strings in config.h. I'm a > > That part might be, but it still won't have handled having .s entries in > config.h where the functions themselves assume they're pointers to malloc()d > memory areas, rather than declared on the stack. Actually, this is exactly what I was pointing this out. > > little more afraid to change these because it will result in breaking a lot of > > configs if this change goes out. > > Specifically? What are you afraid of which this patch potentially won't > cater for anyway? My mistake. I didn't realize that inputbox_activate_cb was the only point of entry for functions in config.h. Clever solution in g_strduping every .s entry that comes in. However, it doesn't seem complete yet: > > @@ -578,8 +579,22 @@ inputbox_activate_cb(GtkEntry *entry, gpointer user_data) { > > if (length >= len && !strncmp(&text[1], commands[i].cmd, len) && (text[len + 1] == ' ' || !text[len + 1])) { > > found = TRUE; > > a.i = commands[i].arg.i; > > - a.s = length > len + 2 ? &text[len + 2] : commands[i].arg.s; > > + > > + if (length > len + 2) { > > + a.s = &text[len + 2]; > > + did_malloc = FALSE; Is there a reason why &text[len+2] here is not g_strdup()d? Because, it causes commands like "echo" and "javascript" segfault. These commands use script as their function, and script g_free()s all .s entries it receives. > > + } else { > > + a.s = g_strdup(commands[i].arg.s ? commands[i].arg.s : ""); > > + did_malloc = TRUE; > > + } > > success = commands[i].func(&a); > > + > > + /* TA: FIXME - likely other commands here won't have free()d. > > + * Maybe they should. > > + */ Some commands definitely do free() by this point (i.e. script). If they do, the following code will most likely cause a segfault, so this should probably be fleshed out a bit more. > > + if (did_malloc && !a.s) > > + g_free(a.s); > > + > > break; > > } > > } > Can you also try and not top-post? Thanks Sure thing. Albert Kim From thomas at xteddy.org Sun Jan 30 03:31:56 2011 From: thomas at xteddy.org (Thomas Adam) Date: Sun, 30 Jan 2011 03:31:56 +0000 Subject: [Vimprobable-users] [PATCH v2 1/1] Make general arguments to commands free-by-callee In-Reply-To: <20110130031720.GA22328@elements.hsd1.ca.comcast.net> References: <20110126212524.GA5875@debian> <20110130023011.GA22142@elements.hsd1.ca.comcast.net> <20110130023516.GB3297@debian.ttn6tadam> <20110130031720.GA22328@elements.hsd1.ca.comcast.net> Message-ID: <20110130033155.GC3297@debian.ttn6tadam> Hello -- On Sat, Jan 29, 2011 at 07:17:20PM -0800, alkim1234 at gmail.com wrote: > Is there a reason why &text[len+2] here is not g_strdup()d? Because, it causes No, my eyes missed it. > commands like "echo" and "javascript" segfault. These commands use script as > their function, and script g_free()s all .s entries it receives. Yes, this is a good observation. > > > + } else { > > > + a.s = g_strdup(commands[i].arg.s ? commands[i].arg.s : ""); > > > + did_malloc = TRUE; > > > + } > > > success = commands[i].func(&a); > > > + > > > + /* TA: FIXME - likely other commands here won't have free()d. > > > + * Maybe they should. > > > + */ > > Some commands definitely do free() by this point (i.e. script). If they do, the > following code will most likely cause a segfault, so this should probably be > fleshed out a bit more. It's sufficient to just do this I think: --------------------------------------------------------------------------------- diff --git a/main.c b/main.c index 3b0db82..e14e763 100644 --- a/main.c +++ b/main.c @@ -564,7 +564,6 @@ inputbox_activate_cb(GtkEntry *entry, gpointer user_data) { int i; size_t len; gboolean success = FALSE, forward = FALSE, found = FALSE; - gboolean did_malloc = FALSE; a.i = HideCompletion; complete(&a); @@ -581,18 +580,16 @@ inputbox_activate_cb(GtkEntry *entry, gpointer user_data) { a.i = commands[i].arg.i; if (length > len + 2) { - a.s = &text[len + 2]; - did_malloc = FALSE; + a.s = g_strdup(&text[len + 2]); } else { a.s = g_strdup(commands[i].arg.s ? commands[i].arg.s : ""); - did_malloc = TRUE; } success = commands[i].func(&a); /* TA: FIXME - likely other commands here won't have free()d. * Maybe they should. */ - if (did_malloc && !a.s) + if (!a.s) g_free(a.s); break; --------------------------------------------------------------------------------- Do you think? I haven't tested it, it just looks a bit better in my head. I know some commands to free(), I am referring to some of them which might receive garbage input (such as ":reload jdjlkdlkj ljlfdjl") but otherwise not expect to have to do anything with it. By this point, we might have malloc()d it, passed it in anyway, and it would be never free()d at all. With the above squahed in to my patch, what results do you get now? -- Thomas Adam -- "It was the cruelest game I've ever played and it's played inside my head." -- "Hush The Warmth", Gorky's Zygotic Mynci. From alkim1234 at gmail.com Sun Jan 30 04:02:52 2011 From: alkim1234 at gmail.com (alkim1234 at gmail.com) Date: Sat, 29 Jan 2011 20:02:52 -0800 Subject: [Vimprobable-users] [PATCH v2 1/1] Make general arguments to commands free-by-callee In-Reply-To: <20110130033155.GC3297@debian.ttn6tadam> References: <20110126212524.GA5875@debian> <20110130023011.GA22142@elements.hsd1.ca.comcast.net> <20110130023516.GB3297@debian.ttn6tadam> <20110130031720.GA22328@elements.hsd1.ca.comcast.net> <20110130033155.GC3297@debian.ttn6tadam> Message-ID: <20110130040252.GA23932@elements.hsd1.ca.comcast.net> > It's sufficient to just do this I think: > > --------------------------------------------------------------------------------- > diff --git a/main.c b/main.c > index 3b0db82..e14e763 100644 > --- a/main.c > +++ b/main.c > @@ -564,7 +564,6 @@ inputbox_activate_cb(GtkEntry *entry, gpointer user_data) { > int i; > size_t len; > gboolean success = FALSE, forward = FALSE, found = FALSE; > - gboolean did_malloc = FALSE; > > a.i = HideCompletion; > complete(&a); > @@ -581,18 +580,16 @@ inputbox_activate_cb(GtkEntry *entry, gpointer user_data) { > a.i = commands[i].arg.i; > > if (length > len + 2) { > - a.s = &text[len + 2]; > - did_malloc = FALSE; > + a.s = g_strdup(&text[len + 2]); > } else { > a.s = g_strdup(commands[i].arg.s ? commands[i].arg.s : ""); > - did_malloc = TRUE; > } > success = commands[i].func(&a); > > /* TA: FIXME - likely other commands here won't have free()d. > * Maybe they should. > */ > - if (did_malloc && !a.s) > + if (!a.s) > g_free(a.s); > > break; What is the above checking for? Perhaps you meant to do if (a.s)? But, then you'll get double-freeing in some commands. > Do you think? I haven't tested it, it just looks a bit better in my head. Yes, I think this looks better. > I know some commands to free(), I am referring to some of > them which might receive garbage input (such as ":reload jdjlkdlkj ljlfdjl") > but otherwise not expect to have to do anything with it. By this point, we > might have malloc()d it, passed it in anyway, and it would be never free()d > at all. Valid point. Do you have any ideas for taking care of the double-freeing? Maybe none of the commands should free, and wrapper functions could be created around the commands that automatically free arguments. So, config.h can use the original commands and other parts of the code can use the wrapper functions. Or, symmetric mallocing/freeing is another option. > With the above squahed in to my patch, what results do you get now? It works! Albert Kim From thomas at xteddy.org Sun Jan 30 04:12:03 2011 From: thomas at xteddy.org (Thomas Adam) Date: Sun, 30 Jan 2011 04:12:03 +0000 Subject: [Vimprobable-users] [PATCH v2 1/1] Make general arguments to commands free-by-callee In-Reply-To: <20110130040252.GA23932@elements.hsd1.ca.comcast.net> References: <20110126212524.GA5875@debian> <20110130023011.GA22142@elements.hsd1.ca.comcast.net> <20110130023516.GB3297@debian.ttn6tadam> <20110130031720.GA22328@elements.hsd1.ca.comcast.net> <20110130033155.GC3297@debian.ttn6tadam> <20110130040252.GA23932@elements.hsd1.ca.comcast.net> Message-ID: <20110130041201.GD3297@debian.ttn6tadam> On Sat, Jan 29, 2011 at 08:02:52PM -0800, alkim1234 at gmail.com wrote: > Valid point. Do you have any ideas for taking care of the double-freeing? No, I think it's fine to ignore it -- that is, if other command instances in the future need to mess with a.s, it will be free()d for us. And with this patch, we're still catering for commands in config.h as before. I think we should go with this: ------------------------- 8< ----------------------------------------------- Author: Thomas Adam Date: Wed Jan 26 19:44:27 2011 +0000 Make general arguments to commands free-by-callee Because most Vimprobable commands now free from the place they're called, ensure commands can still be allocated "on the stack" (that is statically from config.h) by free()ing those if they haven't been free()d already. Ensure we always malloc() for matches we find, and not just take a random memory location; stops needing a silly malloced flag, as everything is malloc()d and free()d where appropriate. diff --git a/main.c b/main.c index 95ad0cd..e14e763 100644 --- a/main.c +++ b/main.c @@ -193,7 +193,7 @@ ascii_bar(int total, int state, char *string) { void webview_load_committed_cb(WebKitWebView *webview, WebKitWebFrame *frame, gpointer user_data) { - Arg a = { .i = Silent, .s = JS_SETUP_HINTS }; + Arg a = { .i = Silent, .s = g_strdup(JS_SETUP_HINTS) }; const char *uri = webkit_web_view_get_uri(webview); update_url(uri); @@ -202,7 +202,7 @@ webview_load_committed_cb(WebKitWebView *webview, WebKitWebFrame *frame, gpointe void webview_load_finished_cb(WebKitWebView *webview, WebKitWebFrame *frame, gpointer user_data) { - Arg a = { .i = Silent, .s = JS_SETUP_INPUT_FOCUS }; + Arg a = { .i = Silent, .s = g_strdup(JS_SETUP_INPUT_FOCUS) }; if (HISTORY_MAX_ENTRIES > 0) history(); @@ -364,7 +364,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { case ModeInsert: if (CLEAN(event->state) == 0 && event->keyval == GDK_Escape) { a.i = Silent; - a.s = "vimprobable_clearfocus()"; + a.s = g_strdup("vimprobable_clearfocus()"); script(&a); a.i = ModeNormal; return set(&a); @@ -383,7 +383,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { case ModeHints: if (CLEAN(event->state) == 0 && event->keyval == GDK_Escape) { a.i = Silent; - a.s = "vimprobable_clear()"; + a.s = g_strdup("vimprobable_clear()"); script(&a); a.i = ModeNormal; count = 0; @@ -437,7 +437,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { memset(inputKey, 0, 5); count = 0; a.i = Silent; - a.s = "vimprobable_cleanup()"; + a.s = g_strdup("vimprobable_cleanup()"); script(&a); a.s = g_strconcat("vimprobable_show_hints('", inputBuffer, "')", NULL); a.i = Silent; @@ -470,7 +470,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { count = 0; memset(inputBuffer, 0, 65); a.i = Silent; - a.s = "vimprobable_cleanup()"; + a.s = g_strdup("vimprobable_cleanup()"); script(&a); a.s = g_strconcat("vimprobable_show_hints()", NULL); a.i = Silent; @@ -478,7 +478,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { update_state(); } else if (strlen(inputBuffer) > 0) { a.i = Silent; - a.s = "vimprobable_cleanup()"; + a.s = g_strdup("vimprobable_cleanup()"); script(&a); /* check how many bytes the last character uses */ for (count = 0; count < 64; count++) { @@ -578,8 +578,20 @@ inputbox_activate_cb(GtkEntry *entry, gpointer user_data) { if (length >= len && !strncmp(&text[1], commands[i].cmd, len) && (text[len + 1] == ' ' || !text[len + 1])) { found = TRUE; a.i = commands[i].arg.i; - a.s = length > len + 2 ? &text[len + 2] : commands[i].arg.s; + + if (length > len + 2) { + a.s = g_strdup(&text[len + 2]); + } else { + a.s = g_strdup(commands[i].arg.s ? commands[i].arg.s : ""); + } success = commands[i].func(&a); + + /* TA: FIXME - likely other commands here won't have free()d. + * Maybe they should. + */ + if (!a.s) + g_free(a.s); + break; } } @@ -1264,7 +1276,7 @@ set(const Arg *arg) { memset(followTarget, 0, 8); strncpy(followTarget, arg->s, 8); a.i = Silent; - a.s = "vimprobable_show_hints()"; + a.s = g_strdup("vimprobable_show_hints()"); script(&a); break; default: @@ -1378,6 +1390,11 @@ script(const Arg *arg) { } } g_free(value); + + /* free() the command string given. */ + if (arg->s) + g_free(arg->s); + return TRUE; } ------------------------- 8< ----------------------------------------------- If you want to squash this in on top of which ever patch it is I've walked all over, please do. I know I've seen something close to this as part of your hinting patch series. -- Thomas Adam -- "It was the cruelest game I've ever played and it's played inside my head." -- "Hush The Warmth", Gorky's Zygotic Mynci. From thomas at xteddy.org Sun Jan 30 05:32:41 2011 From: thomas at xteddy.org (Thomas Adam) Date: Sun, 30 Jan 2011 05:32:41 +0000 Subject: [Vimprobable-users] [PATCH v2 1/1] Make general arguments to commands free-by-callee In-Reply-To: <20110130041201.GD3297@debian.ttn6tadam> References: <20110126212524.GA5875@debian> <20110130023011.GA22142@elements.hsd1.ca.comcast.net> <20110130023516.GB3297@debian.ttn6tadam> <20110130031720.GA22328@elements.hsd1.ca.comcast.net> <20110130033155.GC3297@debian.ttn6tadam> <20110130040252.GA23932@elements.hsd1.ca.comcast.net> <20110130041201.GD3297@debian.ttn6tadam> Message-ID: <20110130053240.GE3297@debian.ttn6tadam> On Sun, Jan 30, 2011 at 04:12:03AM +0000, Thomas Adam wrote: > On Sat, Jan 29, 2011 at 08:02:52PM -0800, alkim1234 at gmail.com wrote: > > Valid point. Do you have any ideas for taking care of the double-freeing? > > No, I think it's fine to ignore it -- that is, if other command instances in > the future need to mess with a.s, it will be free()d for us. And with this > patch, we're still catering for commands in config.h as before. Except of course, now nothing is ever free()d. I'll repeat again, that leaving free()ing up to the caller always gets forgotten -- there's too many examples of this in Vimprobable; and also note that this is still a much cleaner interface to the commands *where it's used* currently -- as both echo() and script() are both functions run for various commands -- you enumerate the areas where this can all be done centrally. So see the following below. It introduces the SAFEFREE() macro (which I stole from FVWM) which sets the pointers it free()s to NULL, this trying to avoid the double-free conditions we might see. Note that g_free(), like free() seems to not to set the pointer to NULL -- I had hoped g_free() might. This is on top of my last patch in this thread. ------------------------- 8< ----------------------------------------------- diff --git a/main.c b/main.c index e14e763..e154de3 100644 --- a/main.c +++ b/main.c @@ -587,10 +587,11 @@ inputbox_activate_cb(GtkEntry *entry, gpointer user_data) { success = commands[i].func(&a); /* TA: FIXME - likely other commands here won't have free()d. - * Maybe they should. + * Maybe they should in the future, that is, so we don't need + * to do this here for commands which rely on processing + * options sent to them in ".s". */ - if (!a.s) - g_free(a.s); + SAFEFREE(a.s); break; } @@ -985,11 +986,10 @@ echo(const Arg *arg) { set_widget_font_and_color(inputbox, urlboxfont[index], urlboxbgcolor[index], urlboxcolor[index]); gtk_entry_set_text(GTK_ENTRY(inputbox), !arg->s ? "" : arg->s); - /* TA: Always free arg->s here, rather than relying on the caller to do - * this. - */ - if (arg->s) - g_free(arg->s); + /* TA: Always free arg->s here, rather than relying on the caller to do + * this. + */ + SAFEFREE(((Arg *)arg)->s); return TRUE; } @@ -1392,8 +1392,7 @@ script(const Arg *arg) { g_free(value); /* free() the command string given. */ - if (arg->s) - g_free(arg->s); + SAFEFREE(((Arg *)arg)->s); return TRUE; } diff --git a/vimprobable.h b/vimprobable.h index 72fe819..9c9fe90 100644 --- a/vimprobable.h +++ b/vimprobable.h @@ -9,6 +9,7 @@ /* macros */ #define LENGTH(x) (sizeof(x)/sizeof(x[0])) +#define SAFEFREE(p) {if (p) {free(p);(p)=NULL;}} /* enums */ enum { ModeNormal, ModePassThrough, ModeSendKey, ModeInsert, ModeHints }; /* modes */ ------------------------- 8< ----------------------------------------------- -- Thomas Adam -- "It was the cruelest game I've ever played and it's played inside my head." -- "Hush The Warmth", Gorky's Zygotic Mynci. From thomas at xteddy.org Sun Jan 30 16:17:06 2011 From: thomas at xteddy.org (Thomas Adam) Date: Sun, 30 Jan 2011 16:17:06 +0000 Subject: [Vimprobable-users] [PATCHi (v2) 1/1] Don't segfault overflowing MAX_LIST_SIZE in complete() Message-ID: <20110130161701.GA5370@debian.ttn6tadam> When completing the command list, at the command prompt, ensure we malloc and then realloc by not assuming this list is initially the length of MAX_LIST_SIZE. Instead, calculate the size of the command list at runtime, and use that value to malloc correctly. This doesn't then attempt to overwrite any memory when realloc()ing. In complete() when trying to realloc() the code path means that we might reach that point before having had that memory used -- so only print the warning realloc() failed if both the original pointer and the new one are both NULL. But we explicitly assign the newly realloc()d pointer to temporary pointers so that we don't clobber the original pointer. In the case originally of overflowing MAX_LIST_SIZE, trying to realloc() beyond that, still using the original pointer, meant that we lost all of the data. That's bad. This does need a bit of a rethink in the future to get rid of the static state of some of the function variables, but this patch doesn't need to address that. --- V2 of this just fixes the case of not bailing on realloc() in legitimate cases. main.c | 38 +++++++++++++++++++++++++++++--------- 1 files changed, 29 insertions(+), 9 deletions(-) diff --git a/main.c b/main.c index 95ad0cd..0bc66b7 100644 --- a/main.c +++ b/main.c @@ -753,12 +753,20 @@ complete(const Arg *arg) { GtkWidget *row_eventbox, *el; GtkBox *_table; GdkColor color; - static GtkWidget *table, **widgets, *top_border; - static char **suggestions, *prefix; + static GtkWidget *table, *top_border; + static char *prefix; + static char **suggestions; + static GtkWidget **widgets; static int n = 0, m, current = -1; str = (char*)gtk_entry_get_text(GTK_ENTRY(inputbox)); len = strlen(str); + + /* Get the length of the list of commands for completion. We need this to + * malloc/realloc correctly. + */ + listlen = LENGTH(commands); + if ((len == 0 || str[0] != ':') && arg->i != HideCompletion) return TRUE; if (prefix) { @@ -788,8 +796,8 @@ complete(const Arg *arg) { return TRUE; if (!widgets) { prefix = g_strdup_printf(str); - widgets = malloc(sizeof(GtkWidget*) * MAX_LIST_SIZE); - suggestions = malloc(sizeof(char*) * MAX_LIST_SIZE); + widgets = malloc(sizeof(GtkWidget*) * listlen); + suggestions = malloc(sizeof(char*) * listlen); top_border = gtk_event_box_new(); gtk_widget_set_size_request(GTK_WIDGET(top_border), 0, 1); gdk_color_parse(completioncolor[2], &color); @@ -800,7 +808,6 @@ complete(const Arg *arg) { highlight = len > 1; if (strchr(str, ' ') == NULL) { /* command completion */ - listlen = LENGTH(commands); for (i = 0; i < listlen; i++) { if (commands[i].cmd == NULL) break; @@ -836,7 +843,7 @@ complete(const Arg *arg) { return FALSE; } memset(entry, 0, 512); - suggurls = malloc(sizeof(char*) * MAX_LIST_SIZE); + suggurls = malloc(sizeof(char*) * listlen); if (suggurls == NULL) { return FALSE; } @@ -845,7 +852,6 @@ complete(const Arg *arg) { strncpy(command, (str + 1), spacepos - 1); if (strlen(command) == 3 && strncmp(command, "set", 3) == 0) { /* browser settings */ - listlen = LENGTH(browsersettings); for (i = 0; i < listlen; i++) { if (n < MAX_LIST_SIZE && strstr(browsersettings[i].name, searchfor) != NULL) { /* match */ @@ -896,8 +902,22 @@ complete(const Arg *arg) { entry = NULL; } } - widgets = realloc(widgets, sizeof(GtkWidget*) * n); - suggestions = realloc(suggestions, sizeof(char*) * n); + /* TA: FIXME - this needs rethinking entirely. */ + { + GtkWidget **widgets_temp = realloc(widgets, sizeof(*widgets) * n); + if (widgets_temp == NULL && widgets == NULL) { + fprintf(stderr, "Couldn't realloc() widgets\n"); + exit(1); + } + widgets = widgets_temp; + + char **suggestions_temp = realloc(suggestions, sizeof(*suggestions) * n); + if (suggestions_temp == NULL && suggestions == NULL) { + fprintf(stderr, "Couldn't realloc() suggestions\n"); + exit(1); + } + suggestions = suggestions_temp; + } if (!n) { gdk_color_parse(completionbgcolor[1], &color); gtk_widget_modify_bg(table, GTK_STATE_NORMAL, &color); -- 1.7.2.3 From thomas at xteddy.org Sun Jan 30 16:19:29 2011 From: thomas at xteddy.org (Thomas Adam) Date: Sun, 30 Jan 2011 16:19:29 +0000 Subject: [Vimprobable-users] [PATCH 1/1] Don't segfault overflowing MAX_LIST_SIZE in complete() In-Reply-To: <20110130023144.GA7226@debian.ttn6tadam> References: <20110130023144.GA7226@debian.ttn6tadam> Message-ID: <20110130161927.GA2145@debian.ttn6tadam> On Sun, Jan 30, 2011 at 02:31:48AM +0000, Thomas Adam wrote: > When completing the command list, at the command prompt, ensure we malloc > and then realloc by not assuming this list is initially the length of > MAX_LIST_SIZE. This was very close. But failed on realloc() where we always end up there first before malloc()ing the data. So invalidate this, and see v2 in a separate patch. I think it looks good now. I would like Andraz Levstik to test it though. -- Thomas Adam -- "It was the cruelest game I've ever played and it's played inside my head." -- "Hush The Warmth", Gorky's Zygotic Mynci. From thomas at xteddy.org Sun Jan 30 21:03:58 2011 From: thomas at xteddy.org (Thomas Adam) Date: Sun, 30 Jan 2011 21:03:58 +0000 Subject: [Vimprobable-users] Implementing run-time download path (save-as dialogue too?) Message-ID: <20110130210355.GA5425@debian.ttn6tadam> Hi, For a while now I've had a patch which makes configuring the location of downloaded files available via ":set". I was going to clean it up and send it as another patch, and realised that there's a much more interesting question. Should we have another option for having a save-as dialogue window? For instance, I am thinking of allowing this anyway: :set download_path ~/some/random/directory/ Which would make Vimprobable put all downloads into the value of download_path. But now, in addition to that I am wondering if there should not be another option which always invokes the save-as dialogue prompt to let the user choose where to put files. What do people think? -- Thomas Adam -- "It was the cruelest game I've ever played and it's played inside my head." -- "Hush The Warmth", Gorky's Zygotic Mynci. From hannes at yllr.net Sun Jan 30 21:08:32 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sun, 30 Jan 2011 22:08:32 +0100 Subject: [Vimprobable-users] Implementing run-time download path (save-as dialogue too?) In-Reply-To: <20110130210355.GA5425@debian.ttn6tadam> References: <20110130210355.GA5425@debian.ttn6tadam> Message-ID: <20110130220832.1196185a@workstation> Hi! Thomas Adam wrote: > :set download_path ~/some/random/directory/ This would be useful. > But now, in addition to that I am wondering if there should not be > another option which always invokes the save-as dialogue prompt to > let the user choose where to put files. This, on the other hand, I don't like too much. I hate the respective GTK dialog. It's a usability nightmare. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From thomas at xteddy.org Sun Jan 30 21:23:41 2011 From: thomas at xteddy.org (Thomas Adam) Date: Sun, 30 Jan 2011 21:23:41 +0000 Subject: [Vimprobable-users] Implementing run-time download path (save-as dialogue too?) In-Reply-To: <20110130220832.1196185a@workstation> References: <20110130210355.GA5425@debian.ttn6tadam> <20110130220832.1196185a@workstation> Message-ID: <20110130212340.GB5425@debian.ttn6tadam> On Sun, Jan 30, 2011 at 10:08:32PM +0100, Hannes Sch??ller wrote: > Hi! Hello, Hannes -- > Thomas Adam wrote: > > :set download_path ~/some/random/directory/ > > This would be useful. Yes. > > But now, in addition to that I am wondering if there should not be > > another option which always invokes the save-as dialogue prompt to > > let the user choose where to put files. > > This, on the other hand, I don't like too much. I hate the respective > GTK dialog. It's a usability nightmare. Yes, but this is no worse than any other $BROWSER currently based on webkit. What I don't want to have to do is later on implement this because a bunch of (new) users suddenly have a need for it. :) FWIW though, I don't like the save-dialogue idea either. :) I will just send the ability to set download_path at runtime then. -- Thomas Adam -- "It was the cruelest game I've ever played and it's played inside my head." -- "Hush The Warmth", Gorky's Zygotic Mynci. From ruskie at codemages.net Mon Jan 31 08:39:50 2011 From: ruskie at codemages.net (=?UTF-8?Q?Andra=C5=BE_'ruskie'_Levstik?=) Date: Mon, 31 Jan 2011 09:39:50 +0100 (CET) Subject: [Vimprobable-users] Implementing run-time download path (save-as dialogue too?) In-Reply-To: <20110130212340.GB5425@debian.ttn6tadam> References: <20110130210355.GA5425@debian.ttn6tadam> <20110130220832.1196185a@workstation> <20110130212340.GB5425@debian.ttn6tadam> Message-ID: :2011-01-30T21:23:Thomas Adam: > > > But now, in addition to that I am wondering if there should not be > > > another option which always invokes the save-as dialogue prompt to > > > let the user choose where to put files. > > > > This, on the other hand, I don't like too much. I hate the respective > > GTK dialog. It's a usability nightmare. > > Yes, but this is no worse than any other $BROWSER currently based on webkit. > What I don't want to have to do is later on implement this because a bunch > of (new) users suddenly have a need for it. :) > > FWIW though, I don't like the save-dialogue idea either. :) I guess I'm one of the rare people that find the GTK save dialog actually usable. I wouldn't see anything wrong with adding it if it could be enabled/disabled with something like :set save_dialog=true|false Regards -- Andra? 'ruskie' Levstik Source Mage GNU/Linux Games/Xorg grimoire guru Re-Alpine Coordinator http://sourceforge.net/projects/re-alpine/ Geek/Hacker/Tinker Ryle hira. From thomas at xteddy.org Mon Jan 31 10:18:48 2011 From: thomas at xteddy.org (Thomas Adam) Date: Mon, 31 Jan 2011 10:18:48 +0000 Subject: [Vimprobable-users] [PATCH v3 1/1] Don't segfault overflowing MAX_LIST_SIZE in complete() Message-ID: <20110131101840.GA19570@abacus.soton.smoothwall.net> When completing the command list, at the command prompt, ensure we malloc and then realloc by not assuming this list is initially the length of MAX_LIST_SIZE. Instead, calculate the size of the command list at runtime, and use that value to malloc correctly. This doesn't then attempt to overwrite any memory when realloc()ing. In complete() when trying to realloc() the code path means that we might reach that point before having had that memory used -- so only print the warning realloc() failed if both the original pointer and the new one are both NULL. But we explicitly assign the newly realloc()d pointer to temporary pointers so that we don't clobber the original pointer. In the case originally of overflowing MAX_LIST_SIZE, trying to realloc() beyond that, still using the original pointer, meant that we lost all of the data. That's bad. This does need a bit of a rethink in the future to get rid of the static state of some of the function variables, but this patch doesn't need to address that. --- V3: Added back in listlen check. God knows what I was thinking. main.c | 38 ++++++++++++++++++++++++++++++-------- 1 files changed, 30 insertions(+), 8 deletions(-) diff --git a/main.c b/main.c index 95ad0cd..30ff8b3 100644 --- a/main.c +++ b/main.c @@ -753,12 +753,20 @@ complete(const Arg *arg) { GtkWidget *row_eventbox, *el; GtkBox *_table; GdkColor color; - static GtkWidget *table, **widgets, *top_border; - static char **suggestions, *prefix; + static GtkWidget *table, *top_border; + static char *prefix; + static char **suggestions; + static GtkWidget **widgets; static int n = 0, m, current = -1; str = (char*)gtk_entry_get_text(GTK_ENTRY(inputbox)); len = strlen(str); + + /* Get the length of the list of commands for completion. We need this to + * malloc/realloc correctly. + */ + listlen = LENGTH(commands); + if ((len == 0 || str[0] != ':') && arg->i != HideCompletion) return TRUE; if (prefix) { @@ -788,8 +796,8 @@ complete(const Arg *arg) { return TRUE; if (!widgets) { prefix = g_strdup_printf(str); - widgets = malloc(sizeof(GtkWidget*) * MAX_LIST_SIZE); - suggestions = malloc(sizeof(char*) * MAX_LIST_SIZE); + widgets = malloc(sizeof(GtkWidget*) * listlen); + suggestions = malloc(sizeof(char*) * listlen); top_border = gtk_event_box_new(); gtk_widget_set_size_request(GTK_WIDGET(top_border), 0, 1); gdk_color_parse(completioncolor[2], &color); @@ -801,7 +809,7 @@ complete(const Arg *arg) { if (strchr(str, ' ') == NULL) { /* command completion */ listlen = LENGTH(commands); - for (i = 0; i < listlen; i++) { + for (i = 0; i < listlen; i++) { if (commands[i].cmd == NULL) break; cmdlen = strlen(commands[i].cmd); @@ -836,7 +844,7 @@ complete(const Arg *arg) { return FALSE; } memset(entry, 0, 512); - suggurls = malloc(sizeof(char*) * MAX_LIST_SIZE); + suggurls = malloc(sizeof(char*) * listlen); if (suggurls == NULL) { return FALSE; } @@ -896,8 +904,22 @@ complete(const Arg *arg) { entry = NULL; } } - widgets = realloc(widgets, sizeof(GtkWidget*) * n); - suggestions = realloc(suggestions, sizeof(char*) * n); + /* TA: FIXME - this needs rethinking entirely. */ + { + GtkWidget **widgets_temp = realloc(widgets, sizeof(*widgets) * n); + if (widgets_temp == NULL && widgets == NULL) { + fprintf(stderr, "Couldn't realloc() widgets\n"); + exit(1); + } + widgets = widgets_temp; + + char **suggestions_temp = realloc(suggestions, sizeof(*suggestions) * n); + if (suggestions_temp == NULL && suggestions == NULL) { + fprintf(stderr, "Couldn't realloc() suggestions\n"); + exit(1); + } + suggestions = suggestions_temp; + } if (!n) { gdk_color_parse(completionbgcolor[1], &color); gtk_widget_modify_bg(table, GTK_STATE_NORMAL, &color); -- 1.7.1