vimprobable-users — Mailing list for Vimprobable users

Re: [Vimprobable-users] [Patches] New hint modes

[Hannes S. <ha...@yl...>]

Applied (with the suggested changes)

Re: [Vimprobable-users] [Patches] New hint modes

[Hannes S. <ha...@yl...>]

Applied

Re: [Vimprobable-users] Modkey patch

[Hannes S. <ha...@yl...>]

Applied

Re: [Vimprobable-users] [PATCH] fix mixed case bookmarks

[Hannes S. <ha...@yl...>]

Applied

Re: [Vimprobable-users] [PATCH] save clipboard before focusing input bar

[Hannes S. <ha...@yl...>]

Applied

Re: [Vimprobable-users] [PATCH] Adapt PATCHES to recent infrastructure changes

[Hannes S. <ha...@yl...>]

Applied

Re: [Vimprobable-users] [PATCH] respect DESTDIR in 'make uninstall'

[Hannes S. <ha...@yl...>]

Applied

Re: [Vimprobable-users] [PATCH] move vimprobablerc man page to correct section

[Hannes S. <ha...@yl...>]

Applied

Re: [Vimprobable-users] [PATCH] Ignore irrelevant modifiers in key events.

[Hannes S. <ha...@yl...>]

Applied

Re: [Vimprobable-users] [PATCH] Fix some more memory leaks

[Hannes S. <ha...@yl...>]

Applied

Re: [Vimprobable-users] [PATCH] Possible fix for crash on :echo

[Hannes S. <ha...@yl...>]

Applied

Re: [Vimprobable-users] [PATCH] Possible fix for crash on :echo

[Hannes S. <ha...@yl...>]

Applied

Re: [Vimprobable-users] [PATCH] Fix crash on completion of long urls from commit 5cfefb1

[Hannes S. <ha...@yl...>]

Applied

[Vimprobable-users] Modkey patch

[matto f. <ma...@ma...>]

Hi,

Enclosed please find a patch to solve the modkey mapping :)

Cheers,

Matto

Re: [Vimprobable-users] [PATCH] fix mixed case bookmarks

[Hut <hu...@la...>]

On Fri, Oct 21, 2011 at 02:45:27PM +0200, Hut wrote:
> Opening bookmarks to a mixed-case URL break when complete_case_sensitive
> is FALSE, since this causes the URL to become all lowercase.  This patch 
> fixes that.
> 
> To reproduce the error:
> 
> bookmark this: http://en.gentoo-wiki.com/wiki/DM-Crypt_with_LUKS
> set complete_case_sensitive in config.h to FALSE
> type :open gent<TAB> until the bookmark appears. It's all lowercase and
> won't work.

Forgot to attach the patch, here it is.

[Vimprobable-users] [PATCH] fix mixed case bookmarks

[Hut <hu...@la...>]

Opening bookmarks to a mixed-case URL break when complete_case_sensitive
is FALSE, since this causes the URL to become all lowercase.  This patch 
fixes that.

To reproduce the error:

bookmark this: http://en.gentoo-wiki.com/wiki/DM-Crypt_with_LUKS
set complete_case_sensitive in config.h to FALSE
type :open gent<TAB> until the bookmark appears. It's all lowercase and
won't work.

[Vimprobable-users] [PATCH] save clipboard before focusing input bar

[Hut <hu...@la...>]

This patch prevents the clipboard from being overwritten by
gtk_widget_grab_focus(inputbox).  Code borrowed from jumanji.

Re: [Vimprobable-users] [Patches] New hint modes

[Daniel C. <dan...@gm...>]

Hi!
On Sat, Oct 01, 2011 at 02:38:58PM +0200, Hannes Schüller wrote:
> If this is working for everybody (please test!), I will consolidate it
> with the other patches currently floating around to create the next
> release version.
> 
> Hannes

This works fine for me. I sent a patch on top of Hans-Peter's download hint
patch that used different xpath expressions to generate hints according to
current hintmode. Now hints for form fields are only shown for commands f, F,
;o ;t ;w. All other modes ignore form fields but hint also for images, so
that's possible to yank or download an image via hinting.

The attached patch is merged onto top of the new hintmodes of Hannes Schüller.

Daniel

Re: [Vimprobable-users] [HOWTO] Debugging Vimprobable with Valgrind

[Daniel C. <dan...@gm...>]

Hi Hans-Peter!

Pretty nice work. Until today it was enough for me to make the glib more
valgrind friendly and to see trough thousands of useless possible memleaks
thrown out by valgrind. With your hints it's more comfortable to check for real
leaks in vimprobable.

Daniel

[Vimprobable-users] [HOWTO] Debugging Vimprobable with Valgrind

[Hans-Peter D. <hpd...@gm...>]

Hi,

Valgrind is a nice tool to debug memory leaks. Here is what I had to do
to make it work well with vimprobable and in particular webkit:

To run vimprobable under valgrind, use the following command:

  G_SLICE=always-malloc G_DEBUG=gc-friendly \
  valgrind --leak-check=full --suppressions=valgrind_suppressions.supp \
           --demangle=no --smc-check=all --num-callers=50 \
           --log-file=valgrind.out ./vimprobable2

G_SLICE and G_DEBUG are there to make glib more valgrind friendly and
are explained at [1].

The various options I used are:

    --leak-check=full: Give details about every leak

    --suppressions: Suppress errors that are unrelated to
        vimprobable. I will attach this file.

    --demangle=no: Webkit is C++ and thus uses mangled C-symbols. Valgrind
        shouldn't try to print the demangled symbols, because we need the
        mangled ones for the suppressions file.

    --smc-check=all: Detect self-modifying code. This is needed for Webkits
        JIT-compiler.

    --num-callers=50: Webkit and glib have very deep stack-traces. Show
        as much as possible of them.

Regarding the suppressions file: Without it, valgrind shows many errors
and leaks in libraries that are not caused by vimprobable. I tried to
suppress all "definitely lost" warnings, that are not vimprobable's
fault. I didn't do anything about "possibly lost" messages, because I'm
unsure where most of them come from. You can skip them for now and
concentrate on "definitely lost".

I tested this (especially the suppressions file) only on one system, so
it could happen that your system shows entirely different errors. You
would have to write your own suppressions in this case.

Also, I certainly didn't exercise all code paths with my testing, so
there could be many more leaks lingering.


HP


[1]: http://developer.gnome.org/glib/2.28/glib-running.html

--
Hans-Peter Deifel

[Vimprobable-users] [PATCH] Adapt PATCHES to recent infrastructure changes

[Hans-Peter D. <hpd...@gm...>]

---
 PATCHES |   29 +++++++++++++++--------------
 1 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/PATCHES b/PATCHES
index f9e8abf..2e47e35 100644
--- a/PATCHES
+++ b/PATCHES
@@ -10,17 +10,18 @@ already a wealth of documentation on the Internet.
 
 The main Vimprobable git repository [2] has two main branches:
 
+master
 vimprobable1
-vimprobable2
 
-which reflect the two supported versions of Vimprobable.
+where master is for development on vimprobable2 and vimprobable1 is obviously
+for vimprobable1 only.
 
-When submitting a patch, the feature should be made on top of the
-vimprobable2 branch, unless there is a good reason for knowing that the fix
-is wholly applicable to vimprobable1.  In the general case though, most
-features are submitted against vimprobable2, and then manually ported to
-vimprobable1 where applicable by the maintainer.  Not all features of
-Vimprobable2 are applicable to Vimprobable1.
+When submitting a patch, the feature should be made on top of the master
+branch, unless there is a good reason for knowing that the fix is wholly
+applicable to vimprobable1.  In the general case though, most features are
+submitted against master, and then manually ported to vimprobable1 where
+applicable by the maintainer.  Not all features of Vimprobable2 are applicable
+to Vimprobable1.
 
 Preamble
 ========
@@ -58,7 +59,7 @@ from one another -- hence, for any feature or patch developed, they should
 be done in their own topic branch, which is branched from the current HEAD
 of origin/vimprobable.  Hence:
 
-$ git checkout vimprobable2
+$ git checkout master
 $ git pull
 $ git checkout my-new-feature
 
@@ -100,11 +101,11 @@ Working out what's changed
 
 Once you're happy with the commits on the "my-new-feature" branch, you'll
 obviously want to check that they still work on top of any new code that
-might have been committed to the vimprobable* branches since you creates the
+might have been committed to the upstream branches since you creates the
 "my-new-feature" branch.  This is important as you'll be basing your patches
 against that.  Hence:
 
-$ git checkout vimprobable2
+$ git checkout master
 $ git pull
 $ git checkout my-new-feature
 
@@ -132,7 +133,7 @@ in a local topic branch; "my-new-feature", and you want to submit them to
 the list.  You've already updated your copy of the vimprobable2 branch, and
 your "my-new-feature" branch is checked-out, hence:
 
-$ git format-patch -M -n --cover-letter -o patch_store vimprobable2
+$ git format-patch -M -n --cover-letter -o patch_store master
 
 Which will place a series of numbered commits in a directory called
 "patch_store".  These can then be sent to the list [3] using the 
@@ -152,6 +153,6 @@ References
 ==========
 
 [1] http://git-scm.com
-[2] http://www.vimprobable.org/vimprobable.git
-[3] vim...@vi...
+[2] https://sourceforge.net/p/vimprobable/code/
+[3] vim...@li...
 [4] http://repo.or.cz -- or -- http://github.com
-- 
1.7.3.4

[Vimprobable-users] [PATCH] Fix some more memory leaks

[Hans-Peter D. <hpd...@gm...>]

---
This patch is on top of Daniel's other memleak patches. There is another leak
in complete(), which I didn't fix because I didn't want to tinker with
complete()'s internals. I added a comment instead. complete() needs a general
cleanup, but I won't have time to do that anytime soon ;)

 main.c |   51 +++++++++++++++++++++++++++++++++++++--------------
 1 files changed, 37 insertions(+), 14 deletions(-)

diff --git a/main.c b/main.c
index e4e79ac..9c7c22e 100644
--- a/main.c
+++ b/main.c
@@ -159,7 +159,7 @@ static SoupCookieJar *file_cookie_jar = NULL;
 static time_t cookie_timeout = 4800;
 static char *cookie_store;
 static void setup_cookies(void);
-static const char *get_cookies(SoupURI *soup_uri);
+static char *get_cookies(SoupURI *soup_uri);
 static void load_all_cookies(void);
 static void new_generic_request(SoupSession *soup_ses, SoupMessage *soup_msg, gpointer unused);
 static void update_cookie_jar(SoupCookieJar *jar, SoupCookie *old, SoupCookie *new);
@@ -426,11 +426,14 @@ set_widget_font_and_color(GtkWidget *widget, const char *font_str, const char *b
 void
 webview_hoverlink_cb(WebKitWebView *webview, char *title, char *link, gpointer data) {
     const char *uri = webkit_web_view_get_uri(webview);
+    char *markup;
 
     memset(rememberedURI, 0, 1024);
     if (link) {
-        gtk_label_set_markup(GTK_LABEL(status_url), g_markup_printf_escaped("<span font=\"%s\">Link: %s</span>", statusfont, link));
+        markup = g_markup_printf_escaped("<span font=\"%s\">Link: %s</span>", statusfont, link);
+        gtk_label_set_markup(GTK_LABEL(status_url), markup);
         strncpy(rememberedURI, link, 1024);
+        g_free(markup);
     } else
         update_url(uri);
 }
@@ -678,16 +681,18 @@ GtkWidget * fill_eventbox(const char * completion_line) {
     GtkBox    * row;
     GtkWidget *row_eventbox, *el;
     GdkColor  color;
-    char      * markup;
+    char      *markup, *markup_tmp;
 
     row = GTK_BOX(gtk_hbox_new(FALSE, 0));
     row_eventbox = gtk_event_box_new();
     gdk_color_parse(completionbgcolor[0], &color);
     gtk_widget_modify_bg(row_eventbox, GTK_STATE_NORMAL, &color);
     el = gtk_label_new(NULL);
+    markup_tmp = g_markup_escape_text(completion_line, strlen(completion_line));
     markup = g_strconcat("<span font=\"", completionfont[0], "\" color=\"", completioncolor[0], "\">",
-        g_markup_escape_text(completion_line, strlen(completion_line)), "</span>", NULL);
+        markup_tmp, "</span>", NULL);
     gtk_label_set_markup(GTK_LABEL(el), markup);
+    g_free(markup_tmp);
     g_free(markup);
     gtk_misc_set_alignment(GTK_MISC(el), 0, 0);
     gtk_box_pack_start(row, el, TRUE, TRUE, 2);
@@ -811,6 +816,7 @@ complete(const Arg *arg) {
                     if (n < MAX_LIST_SIZE && strstr(browsersettings[i].name, searchfor) != NULL) {
                         /* match */
                         fill_suggline(suggline, command, browsersettings[i].name);
+                        /* FIXME(HP): This memory is never freed */
                         suggurls[n] = (char *)malloc(sizeof(char) * 512 + 1);
                         strncpy(suggurls[n], suggline, 512);
                         suggestions[n] = suggurls[n];
@@ -837,6 +843,7 @@ complete(const Arg *arg) {
             elementpointer = elementlist;
             while (elementpointer != NULL) {
                 fill_suggline(suggline, command, elementpointer->element);
+                /* FIXME(HP): This memory is never freed */
                 suggurls[n] = (char *)malloc(sizeof(char) * 512 + 1);
                 strncpy(suggurls[n], suggline, 512);
                 suggestions[n] = suggurls[n];
@@ -1379,8 +1386,10 @@ script(const Arg *arg) {
     jsapi_evaluate_script(arg->s, &value, &message);
     if (message) {
         set_error(message);
+        g_free(message);
         return FALSE;
     }
+    g_free(message);
     if (arg->i != Silent && value) {
         a.i = arg->i;
         a.s = g_strdup(value);
@@ -1964,6 +1973,7 @@ void
 update_url(const char *uri) {
     gboolean ssl = g_str_has_prefix(uri, "https://");
     GdkColor color;
+    gchar *markup;
 #ifdef ENABLE_HISTORY_INDICATOR
     char before[] = " [";
     char after[] = "]";
@@ -1973,14 +1983,16 @@ update_url(const char *uri) {
     if (!back && !fwd)
         before[0] = after[0] = '\0';
 #endif
-    gtk_label_set_markup(GTK_LABEL(status_url), g_markup_printf_escaped(
+    markup = g_markup_printf_escaped(
 #ifdef ENABLE_HISTORY_INDICATOR
         "<span font=\"%s\">%s%s%s%s%s</span>", statusfont, uri,
         before, back ? "+" : "", fwd ? "-" : "", after
 #else
         "<span font=\"%s\">%s</span>", statusfont, uri
 #endif
-    ));
+    );
+    gtk_label_set_markup(GTK_LABEL(status_url), markup);
+    g_free(markup);
     gdk_color_parse(ssl ? sslbgcolor : statusbgcolor, &color);
     gtk_widget_modify_bg(eventbox, GTK_STATE_NORMAL, &color);
     gdk_color_parse(ssl ? sslcolor : statuscolor, &color);
@@ -2054,6 +2066,7 @@ update_state() {
 
     markup = g_markup_printf_escaped("<span font=\"%s\">%s</span>", statusfont, status->str);
     gtk_label_set_markup(GTK_LABEL(status_state), markup);
+    g_free(markup);
 
     g_string_free(status, TRUE);
 }
@@ -2154,6 +2167,7 @@ setup_settings() {
     file_url = g_strdup_printf("file://%s", filename);
     g_object_set(G_OBJECT(settings), "user-stylesheet-uri", file_url, NULL);
     g_free(file_url);
+    g_free(filename);
     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);
@@ -2168,10 +2182,12 @@ setup_settings() {
                 strcpy(new, "http://");
                 memcpy(&new[sizeof("http://") - 1], filename, len + 1);
                 proxy_uri = soup_uri_new(new);
+                g_free(new);
             } else {
                 proxy_uri = soup_uri_new(filename);
             }
             g_object_set(session, "proxy-uri", proxy_uri, NULL);
+            soup_uri_free(proxy_uri);
         }
     }
 }
@@ -2256,22 +2272,24 @@ void
 new_generic_request(SoupSession *session, SoupMessage *soup_msg, gpointer unused) {
 	SoupMessageHeaders *soup_msg_h;
 	SoupURI *uri;
-	const char *cookie_str;
+	char *cookie_str;
 
 	soup_msg_h = soup_msg->request_headers;
 	soup_message_headers_remove(soup_msg_h, "Cookie");
 	uri = soup_message_get_uri(soup_msg);
-	if( (cookie_str = get_cookies(uri)) )
+	if( (cookie_str = get_cookies(uri)) ) {
 		soup_message_headers_append(soup_msg_h, "Cookie", cookie_str);
+		g_free(cookie_str);
+	}
 
 	g_signal_connect_after(G_OBJECT(soup_msg), "got-headers", G_CALLBACK(handle_cookie_request), NULL);
 
 	return;
 }
 
-const char *
+char *
 get_cookies(SoupURI *soup_uri) {
-	const char *cookie_str;
+	char *cookie_str;
 
 	cookie_str = soup_cookie_jar_get_cookies(file_cookie_jar, soup_uri, TRUE);
 
@@ -2281,12 +2299,11 @@ get_cookies(SoupURI *soup_uri) {
 void
 handle_cookie_request(SoupMessage *soup_msg, gpointer unused)
 {
-	GSList *resp_cookie = NULL;
+	GSList *resp_cookie = NULL, *cookie_list;
 	SoupCookie *cookie;
 
-	for(resp_cookie = soup_cookies_from_response(soup_msg);
-		resp_cookie;
-		resp_cookie = g_slist_next(resp_cookie))
+	cookie_list = soup_cookies_from_response(soup_msg);
+	for(resp_cookie = cookie_list; resp_cookie; resp_cookie = g_slist_next(resp_cookie))
 	{
 		SoupDate *soup_date;
 		cookie = soup_cookie_copy((SoupCookie *)resp_cookie->data);
@@ -2294,10 +2311,13 @@ handle_cookie_request(SoupMessage *soup_msg, gpointer unused)
 		if (cookie_timeout && cookie->expires == NULL) {
 			soup_date = soup_date_new_from_time_t(time(NULL) + cookie_timeout * 10);
 			soup_cookie_set_expires(cookie, soup_date);
+			soup_date_free(soup_date);
 		}
 		soup_cookie_jar_add_cookie(file_cookie_jar, cookie);
 	}
 
+	soup_cookies_free(cookie_list);
+
 	return;
 }
 
@@ -2320,10 +2340,12 @@ update_cookie_jar(SoupCookieJar *jar, SoupCookie *old, SoupCookie *new)
 void
 load_all_cookies(void)
 {
+	GSList *cookie_list;
 	file_cookie_jar = soup_cookie_jar_text_new(cookie_store, COOKIES_STORAGE_READONLY);
 
 	/* Put them back in the session store. */
 	GSList *cookies_from_file = soup_cookie_jar_all_cookies(file_cookie_jar);
+	cookie_list = cookies_from_file;
 
 	for (; cookies_from_file;
 	       cookies_from_file = cookies_from_file->next)
@@ -2332,6 +2354,7 @@ load_all_cookies(void)
 	}
 
 	soup_cookies_free(cookies_from_file);
+	g_slist_free(cookie_list);
 
 	return;
 }
-- 
1.7.3.4

Re: [Vimprobable-users] [Patches] New hint modes

[Jason R. <jas...@gm...>]

On 14/10/11 at 08:23am, Hannes Schüller wrote:
> Hi!
> 
> Jason Ryan <jas...@gm...> wrote:
> > On 01/10/11 at 02:38pm, Hannes Sch__ller wrote:
> > One observation after using them for a while: it seems odd (on a
> > standard qwerty kb) to use the semi-colon to activate these modes,
> > and then to have to shift the same key (to access the colon) to
> > activate quick tabs and the :set options.
> > 
> > Obviously, with the current bindings, there would be clashes (the
> > 's', for example), but would it not be simpler to only have the one
> > key to enter command mode?
> 
> So what you're proposing is to use a colon instead of a semicolon to
> activate these hinting modes?
>
Not necessarily: if only one key were to be used, it would probably make more
sense to remain consistent and use the semi-colon.

> The semicolon has been taken from Vimperator. I'd say the point is that
> these are not commands; you don't end them with a carriage return.
> Hence the different trigger.
> 
> Any opnions on this?
> 
As I said, this was just an observation but, carriage return or not, for such a
small set of keybinds, I find it odd to have to remember to hit shift to enter
another mode. Others mileage may vary.

Cheers,

/J

-- 

http://jasonwryan.com/

Re: [Vimprobable-users] [Patches] New hint modes

[Hannes S. <ha...@yl...>]

Hi!

Jason Ryan <jas...@gm...> wrote:
> On 01/10/11 at 02:38pm, Hannes Sch__ller wrote:
> One observation after using them for a while: it seems odd (on a
> standard qwerty kb) to use the semi-colon to activate these modes,
> and then to have to shift the same key (to access the colon) to
> activate quick tabs and the :set options.
> 
> Obviously, with the current bindings, there would be clashes (the
> 's', for example), but would it not be simpler to only have the one
> key to enter command mode?

So what you're proposing is to use a colon instead of a semicolon to
activate these hinting modes?

The semicolon has been taken from Vimperator. I'd say the point is that
these are not commands; you don't end them with a carriage return.
Hence the different trigger.

Any opnions on this?

Hannes

Re: [Vimprobable-users] [Patches] New hint modes

[Jason R. <jas...@gm...>]

On 01/10/11 at 02:38pm, Hannes Schüller wrote:
> Hi,
> 
> this is the next iteration of my patch for additional hinting modes. It
> includes the following functionality:
> 
> - ;s to save a link's destination
> - ;y to yank its destination location
> - ;o to open its location in the current window
> - ;t or ;w to open its location in a new window
> - ;O to generate an :open with hint's URL (like O)
> - ;T or ;W to generate a :tabopen with hint's URL (like T)
> 
> Meaning: I took the semicolon hint modes from Vimperator which make
> sense in our own setup.
> 
> If this is working for everybody (please test!), I will consolidate it
> with the other patches currently floating around to create the next
> release version.
> 
These work great: thank you.

One observation after using them for a while: it seems odd (on a standard qwerty
kb) to use the semi-colon to activate these modes, and then to have to shift the
same key (to access the colon) to activate quick tabs and the :set options.

Obviously, with the current bindings, there would be clashes (the 's', for
example), but would it not be simpler to only have the one key to enter command
mode?

This isn't a complaint/feature request.

Cheers,

/J

-- 

http://jasonwryan.com/