From alkim1234 at gmail.com Thu Jun 9 10:38:07 2011 From: alkim1234 at gmail.com (alkim1234 at gmail.com) Date: Thu, 9 Jun 2011 08:38:07 -0700 Subject: [Vimprobable-users] [PATCH 00/18] New Way to Handle Hinting In-Reply-To: <20110527175229.5013a8d7@workstation> References: <20110503101837.3e3afcbd@workstation> <1306122427-10597-1-git-send-email-alkim1234@gmail.com> <20110527175229.5013a8d7@workstation> Message-ID: <20110609153806.GA3707@elements.hsd1.ca.comcast.net> Hi, > I found one issue which I can't really figure out yet, but > nevertheless, it's a reproducable crash: > > - Go to a website with a text input field (e.g. > http://www.vimprobable.org/mailman/listinfo/vimprobable-users) > - Activate a text input field (the browser should now be in INSERT mode) > - Press escape - the browser crashes > > Any ideas what could be causing this? This was due to "webview_keypress_cb" not duplicating "vimprobable_clearfocus()". It should work with a one line change: commit 197813fa190aedc7974fce8e8fec0843b4a7f0f1 Author: Albert Kim Date: Thu Jun 9 08:30:46 2011 -0700 Escape in insert mode bug fix. There was a bug where vimprobable crashed when pressing escape in insert mode. This was due to the fact that "script" tries to "g_free" "arg->s" if nonzero; "webview_keypress_cb" set the value to be the static string "vimprobable_clearfocus". Fix was simply to duplicate the static string using g_strdup. diff --git a/main.c b/main.c index 73a12ea..2be2aee 100644 --- a/main.c +++ b/main.c @@ -364,7 +364,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { case ModeInsert: if (IS_ESCAPE(event)) { a.i = Silent; - a.s = "vimprobable_clearfocus()"; + a.s = g_strdup("vimprobable_clearfocus()"); script(&a); a.i = ModeNormal; return set(&a); From alkim1234 at gmail.com Thu Jun 9 10:42:01 2011 From: alkim1234 at gmail.com (alkim1234 at gmail.com) Date: Thu, 9 Jun 2011 08:42:01 -0700 Subject: [Vimprobable-users] [PATCH 00/18] New Way to Handle Hinting In-Reply-To: <20110527175504.2f067477@workstation> References: <20110503101837.3e3afcbd@workstation> <1306122427-10597-1-git-send-email-alkim1234@gmail.com> <20110527175504.2f067477@workstation> Message-ID: <20110609154201.GB3707@elements.hsd1.ca.comcast.net> > Sending another mail, because I would like to keep these two issues > separate: > > It is my distinct impression that after applying this patch series, it > takes longer for the hinting mode to work. What I mean is: While > loading a website, in the current release version, I can press f pretty > much immediately when the page starts appearing and it'll all work as > intended. In your version, however, pressing f too early will put the > browser into HINT mode internally, but the hints won't appear on the > page. Could you clarify further? I get the problem of hints not showing, when f is pressed early, on both branches (after/before patch). Albert Kim From hannes at yllr.net Sat Jun 11 07:42:13 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 11 Jun 2011 14:42:13 +0200 Subject: [Vimprobable-users] [Patch] Compile-time definition of external URI handlers Message-ID: <20110611144213.3a9e7c0f@workstation> As discussed on IRC, this patch allows the definition of external applications to handle 'special' URI schemes like mailto:, ftp:// and so on. Before I even think about how to make this configurable at run-time, some testing would be nice. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: external_handlers.patch Type: text/x-patch Size: 6306 bytes Desc: not available URL: -------------- 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 Sat Jun 11 13:19:08 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 11 Jun 2011 20:19:08 +0200 Subject: [Vimprobable-users] [Patch] Compile-time definition of external URI handlers Message-ID: <20110611201908.2093a2fd@workstation> (trying to re-send) As discussed on IRC, this patch allows the definition of external applications to handle 'special' URI schemes like mailto:, ftp:// and so on. Before I even think about how to make this configurable at run-time, some testing would be nice. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: external_handlers.patch Type: text/x-patch Size: 6306 bytes Desc: not available URL: -------------- 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 Tue Jun 14 07:42:36 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Tue, 14 Jun 2011 14:42:36 +0200 Subject: [Vimprobable-users] [Patch] Compile-time definition of external URI handlers Message-ID: <20110614144236.12c7f842@workstation> (trying to re-send) As discussed on IRC, this patch allows the definition of external applications to handle 'special' URI schemes like mailto:, ftp:// and so on. Before I even think about how to make this configurable at run-time, some testing would be nice. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: external_handlers.patch Type: text/x-patch Size: 6306 bytes Desc: not available URL: -------------- 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 Tue Jun 14 07:53:26 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Tue, 14 Jun 2011 14:53:26 +0200 Subject: [Vimprobable-users] Test Message-ID: <20110614145326.6eb93d63@workstation> I've been trying to post to the list unsuccessfully for a few days now. Trying without attachment. Hannes From hannes at yllr.net Tue Jun 14 08:29:42 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Tue, 14 Jun 2011 15:29:42 +0200 Subject: [Vimprobable-users] [Patch] Compile-time definition of external URI handlers Message-ID: <20110614152942.6b0c45cc@workstation> (trying to re-send) As discussed on IRC, this patch allows the definition of external applications to handle 'special' URI schemes like mailto:, ftp:// and so on. Before I even think about how to make this configurable at run-time, some testing would be nice. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: external_handlers.patch Type: text/x-patch Size: 6306 bytes Desc: not available URL: -------------- 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 Tue Jun 14 08:31:34 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Tue, 14 Jun 2011 15:31:34 +0200 Subject: [Vimprobable-users] Test In-Reply-To: <20110614145326.6eb93d63@workstation> References: <20110614145326.6eb93d63@workstation> Message-ID: <20110614153134.321c9292@workstation> Hannes Sch?ller wrote: > I've been trying to post to the list unsuccessfully for a few days > now. Trying without attachment. Sorry for the spam, the mail daemon now seems to be fixed. Thanks, Eiwe! Hannes From thomas at xteddy.org Tue Jun 14 08:44:45 2011 From: thomas at xteddy.org (Thomas Adam) Date: Tue, 14 Jun 2011 13:44:45 +0000 Subject: [Vimprobable-users] [Patch] Compile-time definition of external URI handlers In-Reply-To: <20110611201908.2093a2fd@workstation> References: <20110611201908.2093a2fd@workstation> Message-ID: 2011/6/11 Hannes Sch?ller : > (trying to re-send) > > As discussed on IRC, this patch allows the definition of external > applications to handle 'special' URI schemes like mailto:, ftp:// and > so on. Before I even think about how to make this configurable at > run-time, some testing would be nice. Any reason why you're not just using mailcap for this? -- Thomas Adam From hannes at yllr.net Tue Jun 14 08:50:26 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Tue, 14 Jun 2011 15:50:26 +0200 Subject: [Vimprobable-users] [Patch] Compile-time definition of external URI handlers In-Reply-To: References: <20110611201908.2093a2fd@workstation> Message-ID: <20110614155026.70c77ac3@workstation> Thomas Adam wrote: > 2011/6/11 Hannes Sch?ller : > > As discussed on IRC, this patch allows the definition of external > > applications to handle 'special' URI schemes like mailto:, ftp:// > > and so on. Before I even think about how to make this configurable > > at run-time, some testing would be nice. > > Any reason why you're not just using mailcap for this? Mailcap is MIME centric. This is based on protocol. 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 Tue Jun 14 08:51:21 2011 From: thomas at xteddy.org (Thomas Adam) Date: Tue, 14 Jun 2011 13:51:21 +0000 Subject: [Vimprobable-users] [Patch] Compile-time definition of external URI handlers In-Reply-To: References: <20110611201908.2093a2fd@workstation> Message-ID: On 14 June 2011 13:44, Thomas Adam wrote: > 2011/6/11 Hannes Sch?ller : >> (trying to re-send) >> >> As discussed on IRC, this patch allows the definition of external >> applications to handle 'special' URI schemes like mailto:, ftp:// and >> so on. Before I even think about how to make this configurable at >> run-time, some testing would be nice. > > Any reason why you're not just using mailcap for this? Ah, sorry. This is for protocol schemes, not for specific types. -- Thomas Adam From thomas at xteddy.org Tue Jun 14 08:52:38 2011 From: thomas at xteddy.org (Thomas Adam) Date: Tue, 14 Jun 2011 13:52:38 +0000 Subject: [Vimprobable-users] [PATCH V2 01/10] Allow for :set downloadpath In-Reply-To: <18447.75248.qm@web121006.mail.ne1.yahoo.com> References: <20110217030715.GA13695@debian.ttn6tadam> <20110219102559.35ec13f2@workstation> <18447.75248.qm@web121006.mail.ne1.yahoo.com> Message-ID: On 30 May 2011 20:44, Jason Timrod wrote: > hi, > > what happened with this series? is it under development? ?i am really interested in it Not by me, no. I no longer do any development work for this project, so if you or someone else wants to pick it up, feel free. -- Thomas Adam From jtimrod at yahoo.com Tue Jun 14 14:19:21 2011 From: jtimrod at yahoo.com (Jason Timrod) Date: Tue, 14 Jun 2011 12:19:21 -0700 (PDT) Subject: [Vimprobable-users] [PATCH V2 01/10] Allow for :set downloadpath In-Reply-To: References: <20110217030715.GA13695@debian.ttn6tadam> <20110219102559.35ec13f2@workstation> <18447.75248.qm@web121006.mail.ne1.yahoo.com> Message-ID: <595498.99633.qm@web121015.mail.ne1.yahoo.com> i am not a c programmer. can you not just finish it? TIA! Jason ----- Original Message ----- From: Thomas Adam To: Jason Timrod ; Mailing list for vimprobable users. Cc: Sent: Tuesday, June 14, 2011 1:52 PM Subject: Re: [Vimprobable-users] [PATCH V2 01/10] Allow for :set downloadpath On 30 May 2011 20:44, Jason Timrod wrote: > hi, > > what happened with this series? is it under development? ?i am really interested in it Not by me, no.? I no longer do any development work for this project, so if you or someone else wants to pick it up, feel free. -- Thomas Adam From hannes at yllr.net Thu Jun 16 05:36:54 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Thu, 16 Jun 2011 12:36:54 +0200 Subject: [Vimprobable-users] [PATCH 00/18] New Way to Handle Hinting In-Reply-To: <20110609154201.GB3707@elements.hsd1.ca.comcast.net> References: <20110503101837.3e3afcbd@workstation> <1306122427-10597-1-git-send-email-alkim1234@gmail.com> <20110527175504.2f067477@workstation> <20110609154201.GB3707@elements.hsd1.ca.comcast.net> Message-ID: <20110616123654.028145ff@laptop2.lan.localhost> Hi! alkim1234 at gmail.com wrote: > > Sending another mail, because I would like to keep these two issues > > separate: > > > > It is my distinct impression that after applying this patch series, > > it takes longer for the hinting mode to work. What I mean is: While > > loading a website, in the current release version, I can press f > > pretty much immediately when the page starts appearing and it'll > > all work as intended. In your version, however, pressing f too > > early will put the browser into HINT mode internally, but the hints > > won't appear on the page. > > Could you clarify further? I get the problem of hints not showing, > when f is pressed early, on both branches (after/before patch). I played around with this more, but as much as I try, I can't pinpoint or quantify it. Since it doesn't look as if anyone else is testing this patchset right now, my proposal is to simply merge it into the next release as it is. If what I wrote was a bug report, I would ask for clarification as well and it I couldn't be given any, I would disregard it. No reason not to treat this the same way. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From hpdeifel at gmx.de Fri Jun 17 15:57:16 2011 From: hpdeifel at gmx.de (Hans-Peter Deifel) Date: Fri, 17 Jun 2011 22:57:16 +0200 Subject: [Vimprobable-users] [PATCH V2 2/5] Make search engines configurable In-Reply-To: <1302620915-28950-3-git-send-email-hpdeifel@gmx.de> References: <1302620915-28950-3-git-send-email-hpdeifel@gmx.de> Message-ID: <1308344236-29905-1-git-send-email-hpdeifel@gmx.de> - The new search engines configuration file is read and validated on startup - These search engines take precedence over those from config.h, when looking up shortcuts --- main.c | 40 +++++++++++++--- utilities.c | 136 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ utilities.h | 4 ++ vimprobable.h | 7 +++ 4 files changed, 179 insertions(+), 8 deletions(-) diff --git a/main.c b/main.c index 4a1caf8..6de2be4 100644 --- a/main.c +++ b/main.c @@ -1079,6 +1079,7 @@ open_arg(const Arg *arg) { char *s = arg->s, *p = NULL, *new; Arg a = { .i = NavigationReload }; int len, i; + char *search_uri, *search_term; if (embed) { argv[0] = *args; @@ -1103,14 +1104,16 @@ open_arg(const Arg *arg) { *(p + 1) = '\0'; len = strlen(s); new = NULL, p = strchr(s, ' '); - if (p) /* check for search engines */ - for (i = 0; i < LENGTH(searchengines); i++) - if (!strncmp(s, searchengines[i].handle, p - s)) { - p = soup_uri_encode(++p, "&"); - new = g_strdup_printf(searchengines[i].uri, p); - g_free(p); - break; - } + if (p) { /* check for search engines */ + *p = '\0'; + search_uri = find_uri_for_searchengine(s); + if (search_uri != NULL) { + search_term = soup_uri_encode(p+1, "&"); + new = g_strdup_printf(search_uri, search_term); + g_free(search_term); + } + *p = ' '; + } if (!new) { if (len > 3 && strstr(s, "://")) { /* valid url? */ p = new = g_malloc(len + 1); @@ -2312,6 +2315,7 @@ main(int argc, char *argv[]) { static gboolean ver = false; static gboolean configfile_exists = FALSE; static const char *cfile = NULL; + char *searchengines_file; static GOptionEntry opts[] = { { "version", 'v', 0, G_OPTION_ARG_NONE, &ver, "print version", NULL }, { "embed", 'e', 0, G_OPTION_ARG_STRING, &winid, "embedded", NULL }, @@ -2372,6 +2376,26 @@ main(int argc, char *argv[]) { g_free(configfile); } + make_searchengines_list(searchengines, LENGTH(searchengines)); + + /* read searchengines. */ + searchengines_file = g_strdup_printf(SEARCHENGINES_STORAGE_FILENAME); + switch (read_searchengines(searchengines_file)) { + case SYNTAX_ERROR: + a.i = Error; + a.s = g_strdup_printf("Syntax error in searchengines file '%s'", searchengines_file); + echo(&a); + break; + case READING_FAILED: + a.i = Error; + a.s = g_strdup_printf("Could not read searchengines file '%s'", searchengines_file); + echo(&a); + break; + default: + break; + } + g_free(searchengines_file); + /* command line argument: URL */ if (argc > 1) { strncpy(url, argv[argc - 1], 255); diff --git a/utilities.c b/utilities.c index 74d0883..3c9590a 100644 --- a/utilities.c +++ b/utilities.c @@ -19,6 +19,7 @@ extern KeyList *keylistroot; extern Key keys[]; extern char *error_msg; extern gboolean complete_case_sensitive; +static GList *dynamic_searchengines = NULL; gboolean read_rcfile(const char *config) { @@ -639,3 +640,138 @@ count_list(Listelement *elementlist) return n; } + +/* split the string at the first occurence of whitespace and return the + * position of the second half. + * Unlike strtok, the substrings can be empty and the second string is + * stripped of trailing and leading whitespace. + * Return -1 if `string' contains no whitespace */ +static int split_string_at_whitespace(char *string) +{ + int index = strcspn(string, "\n\t "); + if (string[index] != '\0') { + string[index++] = 0; + g_strstrip(string+index); + return index; + } + return -1; +} + +/* return TRUE, if the string contains exactly one unescaped %s and no other + * printf directives */ +static gboolean sanity_check_search_url(const char *string) +{ + int was_percent_char = 0, percent_s_count = 0; + + for (; *string; string++) { + switch (*string) { + case '%': + was_percent_char = !was_percent_char; + break; + case 's': + if (was_percent_char) + percent_s_count++; + was_percent_char = 0; + break; + default: + if (was_percent_char) + return FALSE; + was_percent_char = 0; + break; + } + } + + return !was_percent_char && percent_s_count == 1; +} + +enum ConfigFileError +read_searchengines(const char *filename) +{ + FILE *file; + char buffer[BUFFERSIZE], c; + int linum = 0, index; + gboolean found_malformed_lines = FALSE; + Searchengine *new; + + if (access(filename, F_OK) != 0) + return FILE_NOT_FOUND; + + file = fopen(filename, "r"); + if (file == NULL) + return READING_FAILED; + + while (fgets(buffer, BUFFERSIZE, file)) { + linum++; + + /* skip empty lines */ + if (!strcmp(buffer, "\n")) continue; + + /* skip too long lines */ + if (buffer[strlen(buffer)-1] != '\n') { + c = getc(file); + if (c != EOF) { /* this is not the last line */ + while ((c=getc(file)) != EOF && c != '\n'); + fprintf(stderr, "searchengines: syntax error on line %d\n", linum); + found_malformed_lines = TRUE; + continue; + } + } + + /* split line at whitespace */ + index = split_string_at_whitespace(buffer); + + if (index < 0 || buffer[0] == '\0' || buffer[index] == '\0' + || !sanity_check_search_url(buffer+index)) { + fprintf(stderr, "searchengines: syntax error on line %d\n", linum); + found_malformed_lines = TRUE; + continue; + } + + new = malloc(sizeof(Searchengine)); + if (new == NULL) { + fprintf(stderr, "Memory exhausted while loading search engines.\n"); + exit(EXIT_FAILURE); + } + + new->handle = g_strdup(buffer); + new->uri = g_strdup(buffer+index); + + dynamic_searchengines = g_list_prepend(dynamic_searchengines, new); + } + + if (ferror(file)) { + fclose(file); + return READING_FAILED; + } + + fclose(file); + + return found_malformed_lines ? SYNTAX_ERROR : SUCCESS; +} + +void make_searchengines_list(Searchengine *searchengines, int length) +{ + int i; + for (i = 0; i < length; i++, searchengines++) { + dynamic_searchengines = g_list_prepend(dynamic_searchengines, searchengines); + } +} + +/* find a searchengine with a given handle and return its URI or NULL if + * nothing is found. + * The returned string is internal and must not be freed or modified. */ +char *find_uri_for_searchengine(const char *handle) +{ + GList *l; + + if (dynamic_searchengines != NULL) { + for (l = dynamic_searchengines; l; l = g_list_next(l)) { + Searchengine *s = (Searchengine*)l->data; + if (!strcmp(s->handle, handle)) { + return s->uri; + } + } + } + + return NULL; +} diff --git a/utilities.h b/utilities.h index 261d213..301c973 100644 --- a/utilities.h +++ b/utilities.h @@ -30,3 +30,7 @@ Listelement * complete_list(const char *searchfor, const int mode, Listelement * Listelement * add_list(const char *element, Listelement *elementlist); int count_list(Listelement *elementlist); void free_list(Listelement *elementlist); + +enum ConfigFileError read_searchengines(const char *filename); +char *find_uri_for_searchengine(const char *handle); +void make_searchengines_list(Searchengine *searchengines, int length); diff --git a/vimprobable.h b/vimprobable.h index 9732bc9..4f95fca 100644 --- a/vimprobable.h +++ b/vimprobable.h @@ -148,6 +148,13 @@ typedef struct { char element[255]; } Listelement; +enum ConfigFileError { + SUCCESS = 0, + FILE_NOT_FOUND = -1, + READING_FAILED = -2, + SYNTAX_ERROR = -3 +}; + /* constants */ #define MOUSE_BUTTON_1 1 #define MOUSE_BUTTON_2 2 -- 1.7.3.4 From hpdeifel at gmx.de Fri Jun 17 15:58:07 2011 From: hpdeifel at gmx.de (Hans-Peter Deifel) Date: Fri, 17 Jun 2011 22:58:07 +0200 Subject: [Vimprobable-users] [PATCH V2 3/5] Mention search engines in the man page In-Reply-To: <1302620915-28950-4-git-send-email-hpdeifel@gmx.de> References: <1302620915-28950-4-git-send-email-hpdeifel@gmx.de> Message-ID: <1308344287-29948-1-git-send-email-hpdeifel@gmx.de> --- vimprobable2.1 | 44 ++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 44 insertions(+), 0 deletions(-) diff --git a/vimprobable2.1 b/vimprobable2.1 index 71f2c49..e8ca18f 100644 --- a/vimprobable2.1 +++ b/vimprobable2.1 @@ -265,6 +265,48 @@ Store current URI as quickmark 4 q4 Recall quickmark 4 +.SH SEARCHENGINES + +Searchengines let you submit queries to web search engines and similar sites +without having to type the complete URL or visit the page first. + +For example, if +.I ex +is defined as the shortcut for the search at example.com, you can use "ex +search term" instead of an URL to search there for "search term". + +The following search engines (and shortcuts) are already defined in config.h: + +.IP i +http://ixquick.com/do/metasearch.pl?query=%s +.IP s +https://ssl.scroogle.org/cgi-bin/nbbwssl.cgi?Gw=%s +.IP w +https://secure.wikimedia.org/wikipedia/en/w/index.php?title=Special%%3ASearch&search=%s&go=Go +.IP wd +https://secure.wikimedia.org/wikipedia/de/w/index.php?title=Special%%3ASearch&search=%s&go=Go + +.P + +You can always overwrite them or define your own in +.I $HOME/.config/vimprobable/searchengines. +In this file, every line defines one shortcut for one URL in the following +format (without the angle brackets): + +.RS 4 + +.RE + +where the %s serves as a placeholder for the search term. Other percent signs +in the URL have to be escaped as %%\&. + +.B Default search engine + +If Vimprobable doesn't recognize an address as a valid URL or query to one of the +defined search engines, it will use the default search engine instead. See +.BR vimprobablerc (1) +on how to set this default. + .SH FILES Please make sure you create these files before running the browser. @@ -275,6 +317,8 @@ file is required if you want to use cookies. .I $HOME/.config/vimprobable/bookmarks +.I $HOME/.config/vimprobable/searchengines + .I $HOME/.config/vimprobable/cookies .I $HOME/.config/vimprobable/history -- 1.7.3.4 From hannes at yllr.net Mon Jun 20 12:28:03 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Mon, 20 Jun 2011 19:28:03 +0200 Subject: [Vimprobable-users] [PATCH 0/5] Configurable search engines In-Reply-To: <1302620915-28950-1-git-send-email-hpdeifel@gmx.de> References: <1302620915-28950-1-git-send-email-hpdeifel@gmx.de> Message-ID: <20110620192803.567b5248@workstation> Patchset merged - thanks! 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 Mon Jun 20 13:22:50 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Mon, 20 Jun 2011 20:22:50 +0200 Subject: [Vimprobable-users] [PATCH 00/18] New Way to Handle Hinting In-Reply-To: <1306122427-10597-1-git-send-email-alkim1234@gmail.com> References: <20110503101837.3e3afcbd@workstation> <1306122427-10597-1-git-send-email-alkim1234@gmail.com> Message-ID: <20110620202250.5ffa1a3a@workstation> Patchset applied & ported to Vimprobable1 branch. Thanks again! 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 Mon Jun 20 14:01:24 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Mon, 20 Jun 2011 21:01:24 +0200 Subject: [Vimprobable-users] Vimprobable 0.9.22.0 & Vimprobable2 0.9.9.0 released! Message-ID: <20110620210124.5250fed3@workstation> Hello everone, Codename "long overdue" is finally out! These new versions include some bigger chances, so the time since the last release is more than made up for. So what's new in detail? New Features: - Settings to enable and disable inputbox and statusbar (Hannes Schueller) - Vimprobable2 only - Execution of arbitrary colon commands in the config file (Hannes Schueller) - Vimprobable2 only - Make search engines configurable (Hans-Peter Deifel) - Vimprobable 2 only - New way to handle hinting (Albert Kim) Bugfixes: - Boundary checks to avoid undefined overflow effects (Hannes Schueller) - Problems with free'd memory breaking command history (Hannes Schueller) - Don't open new window when Ctrl+left-clicking on empty space (Hans-Peter Deifel) - Prevent crash if feedback string contains control sequences (Hans-Peter Deifel) One patch (by myself) which is currently on the mailing list has not been taken into account for this release. This is due to aforementioned long time - we really had to get this one out. All the more reason to also look forward to the release *after* this one :) 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 Mon Jun 20 15:23:17 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Mon, 20 Jun 2011 22:23:17 +0200 Subject: [Vimprobable-users] [Patches] Two new hint modes Message-ID: <20110620222317.7220d2a4@workstation> Hi, based on the excellent change to use the inputbox for hinting, I have implemented two simple new modes: - download link target (acticated by ";") - yank link URL to clipboard (activated by "#") Each is in its own (mutually exclusive) patch; let me know what you think and if you encounter strange behaviour. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: download-hints.patch Type: text/x-patch Size: 4714 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: yank-link-hints.patch Type: text/x-patch Size: 3957 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From danielcarl at gmx.de Mon Jun 20 15:55:43 2011 From: danielcarl at gmx.de (Daniel Carl) Date: Mon, 20 Jun 2011 22:55:43 +0200 Subject: [Vimprobable-users] Error in commit 10cadca2933a0cade93e Message-ID: <20110620205543.GA6340@linnea> I tested the new commited patches on github.org. The commit "boundary check for user input for internal settings this avoids funny overflow effects" seems to introduce an error. If i start vimprobable2 on terminal and press a key, for example ESC, f or F, following messages are written to terminal: (vimprobable2:5032): Pango-CRITICAL **: pango_font_description_from_string: assertion `str != NULL' failed Daniel From hannes at yllr.net Tue Jun 21 11:47:43 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Tue, 21 Jun 2011 18:47:43 +0200 Subject: [Vimprobable-users] Error in commit 10cadca2933a0cade93e In-Reply-To: <20110620205543.GA6340@linnea> References: <20110620205543.GA6340@linnea> Message-ID: <20110621184743.1e36af04@workstation> Hello Daniel! Daniel Carl wrote: > The commit "boundary check for user input for internal settings this > avoids funny overflow effects" seems to introduce an error. If i > start vimprobable2 on terminal and press a key, for example ESC, f or > F, following messages are written to terminal: > > (vimprobable2:5032): Pango-CRITICAL **: > pango_font_description_from_string: assertion `str != NULL' failed I can't reproduce that. Do you have any wonky font settings? E.g. telling the browser to use a non-existent font? Anyone else who has similar problems? 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 Tue Jun 21 11:53:19 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Tue, 21 Jun 2011 18:53:19 +0200 Subject: [Vimprobable-users] [Patch] Compile-time definition of external URI handlers In-Reply-To: <20110611144213.3a9e7c0f@workstation> References: <20110611144213.3a9e7c0f@workstation> Message-ID: <20110621185319.77456d1a@workstation> Here is a new version of the same patch which applies to the current release - for those who cannot wait :) Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: external_handlers.patch Type: text/x-patch Size: 6211 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From danielcarl at gmx.de Tue Jun 21 16:23:13 2011 From: danielcarl at gmx.de (danielcarl at gmx.de) Date: Tue, 21 Jun 2011 23:23:13 +0200 Subject: [Vimprobable-users] Error in commit 10cadca2933a0cade93e In-Reply-To: <20110621184743.1e36af04@workstation> References: <20110620205543.GA6340@linnea> <20110621184743.1e36af04@workstation> Message-ID: <20110621212313.212350@gmx.net> Hello Hannes, seems that my font config was wrong! I removed my miprobablerc file and the message didn't appear. This commmit wasn't a bug. Thank you for the tip. Daniel -------- Original-Nachricht -------- > Datum: Tue, 21 Jun 2011 18:47:43 +0200 > Von: "Hannes Sch?ller" > An: vimprobable-users at vimprobable.org > Betreff: Re: [Vimprobable-users] Error in commit 10cadca2933a0cade93e > Hello Daniel! > > Daniel Carl wrote: > > The commit "boundary check for user input for internal settings this > > avoids funny overflow effects" seems to introduce an error. If i > > start vimprobable2 on terminal and press a key, for example ESC, f or > > F, following messages are written to terminal: > > > > (vimprobable2:5032): Pango-CRITICAL **: > > pango_font_description_from_string: assertion `str != NULL' failed > > I can't reproduce that. Do you have any wonky font settings? E.g. > telling the browser to use a non-existent font? Anyone else who has > similar problems? > > Hannes -- Daniel Carl Gustav-Fischer-Stra?e 33 07745 Jena 0176/20166455 Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de From danielcarl at gmx.de Tue Jun 21 17:10:06 2011 From: danielcarl at gmx.de (danielcarl at gmx.de) Date: Wed, 22 Jun 2011 00:10:06 +0200 Subject: [Vimprobable-users] Error in commit 10cadca2933a0cade93e In-Reply-To: <20110621184743.1e36af04@workstation> References: <20110620205543.GA6340@linnea> <20110621184743.1e36af04@workstation> Message-ID: <20110621221006.288580@gmx.net> Hello Hannes, I removed all entries from vimprobablerc an added them step by step. The font itself isn't the problem but all color definition cause the error. Until the named commit following worked fine: set statuscolor=#fff But none of the following definition will work: set statuscolor=#fff set statuscolor=#ffffff set statuscolor="#ffffff" I think there is already somthing wrong with the color settings. If i set the constant MAX_SETTING_SIZE to 12 or lower, setting of colors to runtime works fine, but higher values cause the error. Daniel -- Daniel Carl Gustav-Fischer-Stra?e 33 07745 Jena 0176/20166455 Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de From hannes at yllr.net Wed Jun 22 11:49:14 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Wed, 22 Jun 2011 18:49:14 +0200 Subject: [Vimprobable-users] Error in commit 10cadca2933a0cade93e In-Reply-To: <20110621221006.288580@gmx.net> References: <20110620205543.GA6340@linnea> <20110621184743.1e36af04@workstation> <20110621221006.288580@gmx.net> Message-ID: <20110622184914.63959272@workstation> Hi! danielcarl at gmx.de wrote: > I removed all entries from vimprobablerc an added them step by step. > The font itself isn't the problem but all color definition cause the > error. > > Until the named commit following worked fine: > set statuscolor=#fff > > But none of the following definition will work: > set statuscolor=#fff > set statuscolor=#ffffff > set statuscolor="#ffffff" > > I think there is already somthing wrong with the color settings. If i > set the constant MAX_SETTING_SIZE to 12 or lower, setting of colors > to runtime works fine, but higher values cause the error. Thank you, Daniel, for this great analysis! Please update to version 0.9.9.1 (just pushed into the repository) - that should fix the issue. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From danielcarl at gmx.de Wed Jun 22 15:50:55 2011 From: danielcarl at gmx.de (Daniel Carl) Date: Wed, 22 Jun 2011 22:50:55 +0200 Subject: [Vimprobable-users] [PATCH] Feedback for yank Message-ID: <20110622205055.GA18783@linnea> Hello, I found it a little confusing to get yank feedback for yanking current url but not fo yanking marked text like the vimperator plugin does. I found myself pressing multiple times Y because i got no feedback about the yanking. Maybe following patch would be also interesting for someone else. Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: added-yank-feedback.patch Type: text/x-diff Size: 2130 bytes Desc: not available URL: From alkim1234 at gmail.com Tue Jun 28 18:49:30 2011 From: alkim1234 at gmail.com (alkim1234 at gmail.com) Date: Tue, 28 Jun 2011 16:49:30 -0700 Subject: [Vimprobable-users] [PATCH 00/18] New Way to Handle Hinting In-Reply-To: <20110616123654.028145ff@laptop2.lan.localhost> References: <20110503101837.3e3afcbd@workstation> <1306122427-10597-1-git-send-email-alkim1234@gmail.com> <20110527175504.2f067477@workstation> <20110609154201.GB3707@elements.hsd1.ca.comcast.net> <20110616123654.028145ff@laptop2.lan.localhost> Message-ID: <20110628234930.GD1753@elements.gateway.2wire.net> > I played around with this more, but as much as I try, I can't pinpoint > or quantify it. Since it doesn't look as if anyone else is testing this > patchset right now, my proposal is to simply merge it into the next > release as it is. If what I wrote was a bug report, I would ask for > clarification as well and it I couldn't be given any, I would disregard > it. No reason not to treat this the same way. Great. Be sure to me know if you do manage to pinpoint what you're talking about. Albert