From rtlmlbi at yahoo.de Wed Mar 9 21:47:46 2011 From: rtlmlbi at yahoo.de (Absender) Date: Wed, 9 Mar 2011 21:47:46 +0000 (GMT) Subject: [Vimprobable-users] BUG :open fi TAB closes vimprobable2 Message-ID: <723790.98385.qm@web24609.mail.ird.yahoo.com> Hi, if I try to complete an url that begins with fi (:open fi TAB), vimprobable2 closes. I do not know witch of the following information is relevant or if it is enough to reproduce the error: - I use Arch Liunx - I use xmonad as windowmanager - I compiled with the changes described in http://wiki.neo-layout.org/ticket/245 From thomas at xteddy.org Wed Mar 9 21:51:50 2011 From: thomas at xteddy.org (Thomas Adam) Date: Wed, 9 Mar 2011 21:51:50 +0000 Subject: [Vimprobable-users] BUG :open fi TAB closes vimprobable2 In-Reply-To: <723790.98385.qm@web24609.mail.ird.yahoo.com> References: <723790.98385.qm@web24609.mail.ird.yahoo.com> Message-ID: <20110309215149.GC2021@debian.ttn6tadam> On Wed, Mar 09, 2011 at 09:47:46PM +0000, Absender wrote: > Hi, > > if I try to complete an url that begins with fi (:open fi TAB), vimprobable2 > closes. > > I do not know witch of the following information is relevant or if it is enough > to reproduce the error: > - I use Arch Liunx > - I use xmonad as windowmanager > - I compiled with the changes described in http://wiki.neo-layout.org/ticket/245 I don't speak German, but the suggestion looks peripheral to this. Can you please get the Git sources from here: git clone -b vimprobable2 http://vimprobable.org/vimprobable.git run: "make V_DEBUG=1" And then repeat your steps -- if it segfaults, there should be a core file in the CWD -- assuming your ulimit allows for corefile creation (c.f. "ulimit -c unlimited"). I can't reproduce this, by the way. -- Thomas Adam -- "Deep in my heart I wish I was wrong. But deep in my heart I know I am not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.) From rtlmlbi at yahoo.de Wed Mar 9 22:42:39 2011 From: rtlmlbi at yahoo.de (Absender) Date: Wed, 09 Mar 2011 23:42:39 +0100 Subject: [Vimprobable-users] BUG :open fi TAB closes vimprobable2 In-Reply-To: <20110309215149.GC2021@debian.ttn6tadam> References: <723790.98385.qm@web24609.mail.ird.yahoo.com> <20110309215149.GC2021@debian.ttn6tadam> Message-ID: <4D78025F.2070809@yahoo.de> Am 09.03.2011 22:51, Thomas Adam schrieb: > On Wed, Mar 09, 2011 at 09:47:46PM +0000, Absender wrote: >> Hi, >> >> if I try to complete an url that begins with fi (:open fi TAB), vimprobable2 >> closes. >> >> I do not know witch of the following information is relevant or if it is enough >> to reproduce the error: >> - I use Arch Liunx >> - I use xmonad as windowmanager >> - I compiled with the changes described in http://wiki.neo-layout.org/ticket/245 > > I don't speak German, but the suggestion looks peripheral to this. > > Can you please get the Git sources from here: > > git clone -b vimprobable2 http://vimprobable.org/vimprobable.git > > run: > > "make V_DEBUG=1" I did it. Now it does not close. But the first entries of the completion list do not contain any fi. If I try it with fip TAB the first entries start with fip? > And then repeat your steps -- if it segfaults, there should be a core file > in the CWD -- assuming your ulimit allows for corefile creation (c.f. > "ulimit -c unlimited"). I do not understand this last section. From thomas at xteddy.org Wed Mar 9 22:46:45 2011 From: thomas at xteddy.org (Thomas Adam) Date: Wed, 9 Mar 2011 22:46:45 +0000 Subject: [Vimprobable-users] BUG :open fi TAB closes vimprobable2 In-Reply-To: <4D78025F.2070809@yahoo.de> References: <723790.98385.qm@web24609.mail.ird.yahoo.com> <20110309215149.GC2021@debian.ttn6tadam> <4D78025F.2070809@yahoo.de> Message-ID: <20110309224645.GE2021@debian.ttn6tadam> On Wed, Mar 09, 2011 at 11:42:39PM +0100, Absender wrote: > Am 09.03.2011 22:51, Thomas Adam schrieb: > > On Wed, Mar 09, 2011 at 09:47:46PM +0000, Absender wrote: > >> Hi, > >> > >> if I try to complete an url that begins with fi (:open fi TAB), vimprobable2 > >> closes. > >> > >> I do not know witch of the following information is relevant or if it is enough > >> to reproduce the error: > >> - I use Arch Liunx > >> - I use xmonad as windowmanager > >> - I compiled with the changes described in http://wiki.neo-layout.org/ticket/245 > > > > I don't speak German, but the suggestion looks peripheral to this. > > > > Can you please get the Git sources from here: > > > > git clone -b vimprobable2 http://vimprobable.org/vimprobable.git > > > > run: > > > > "make V_DEBUG=1" > > I did it. Now it does not close. But the first entries of the completion > list do not contain any fi. If I try it with fip TAB the first entries > start with fip? Works fine for me. -- Thomas Adam -- "Deep in my heart I wish I was wrong. But deep in my heart I know I am not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.) From hannes at yllr.net Thu Mar 10 17:01:34 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Thu, 10 Mar 2011 18:01:34 +0100 Subject: [Vimprobable-users] BUG :open fi TAB closes vimprobable2 In-Reply-To: <4D78025F.2070809@yahoo.de> References: <723790.98385.qm@web24609.mail.ird.yahoo.com> <20110309215149.GC2021@debian.ttn6tadam> <4D78025F.2070809@yahoo.de> Message-ID: <20110310180134.7c175f03@workstation> Hi! Absender wrote: > Am 09.03.2011 22:51, Thomas Adam schrieb: > > On Wed, Mar 09, 2011 at 09:47:46PM +0000, Absender wrote: > >> if I try to complete an url that begins with fi (:open fi TAB), > >> vimprobable2 closes. > >> > >> I do not know witch of the following information is relevant or if > >> it is enough to reproduce the error: > >> - I use Arch Liunx > >> - I use xmonad as windowmanager > >> - I compiled with the changes described in > >> http://wiki.neo-layout.org/ticket/245 > > > > I don't speak German, but the suggestion looks peripheral to this. > > > > Can you please get the Git sources from here: > > > > git clone -b vimprobable2 http://vimprobable.org/vimprobable.git > > > > run: > > > > "make V_DEBUG=1" > > I did it. Now it does not close. But the first entries of the > completion list do not contain any fi. If I try it with fip TAB the > first entries start with fip? If it doesn't crash anymore, I'm assuming you simply encountered a bug in an older version before which has been fixed by now. As for completion results "not containing" the search string, keep in mind that the completion only lists the URLs. The match might have been found in the associated title or a tag as well. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From mtreibton at googlemail.com Thu Mar 17 21:33:27 2011 From: mtreibton at googlemail.com (Michael Treibton) Date: Thu, 17 Mar 2011 21:33:27 +0000 Subject: [Vimprobable-users] Input-focus on text fields spawns new window - why? Message-ID: hi all, i'm assuming this is a Javascript change on some sites, but recently ive noticed that clicking in certain elements on a page - noticeably text fields will spawn a new vimprobale window, sometimes this opens up the same page, and sometimes opens up a blank page. i see this most when looking at youporn.com - but also on other sites. i have to then :set scripts off click and then: :set scripts on again. is there a better solution? Thanks, Michael From hannes at yllr.net Thu Mar 17 22:34:13 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Thu, 17 Mar 2011 23:34:13 +0100 Subject: [Vimprobable-users] Input-focus on text fields spawns new window - why? In-Reply-To: References: Message-ID: <20110317233413.0e105d83@workstation> Hi! Michael Treibton wrote: > i'm assuming this is a Javascript change on some sites, but recently > ive noticed that clicking in certain elements on a page - noticeably > text fields will spawn a new vimprobale window, sometimes this opens > up the same page, and sometimes opens up a blank page. I can think of two reasons: 1. A popup function to show you ads. 2. Some XMLRPC code (probably a "suggestion" function) trying to reference a frame/iframe which doesn't actually exist. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From mtreibton at googlemail.com Thu Mar 17 22:43:07 2011 From: mtreibton at googlemail.com (Michael Treibton) Date: Thu, 17 Mar 2011 22:43:07 +0000 Subject: [Vimprobable-users] Input-focus on text fields spawns new window - why? In-Reply-To: <20110317233413.0e105d83@workstation> References: <20110317233413.0e105d83@workstation> Message-ID: 2011/3/17 Hannes Sch?ller : > Hi! > > Michael Treibton wrote: >> i'm assuming this is a Javascript change on some sites, but recently >> ive noticed that clicking in certain elements on a page - noticeably >> text fields will spawn a new vimprobale window, ?sometimes this opens >> up the same page, and sometimes opens up a blank page. > > I can think of two reasons: > > 1. A popup function to show you ads. > > 2. Some XMLRPC code (probably a "suggestion" function) trying to > reference a frame/iframe which doesn't actually exist. Let me guess - Vimprobable doesn't provide a solution for either of these? Michael From hpdeifel at gmx.de Thu Mar 17 23:16:10 2011 From: hpdeifel at gmx.de (Hans-Peter Deifel) Date: Fri, 18 Mar 2011 00:16:10 +0100 Subject: [Vimprobable-users] Input-focus on text fields spawns new window - why? In-Reply-To: References: Message-ID: <20110317231610.GA10364@deepsilver> On 21:33 Thu 17 Mar , Michael Treibton wrote: > hi all, > > i'm assuming this is a Javascript change on some sites, but recently > ive noticed that clicking in certain elements on a page - noticeably > text fields will spawn a new vimprobale window, sometimes this opens > up the same page, and sometimes opens up a blank page. > > i see this most when looking at youporn.com - but also on other sites. > > i have to then :set scripts off > > click > > and then: > > :set scripts on > > again. is there a better solution? try to focus the input field via hints. I described this problem in a mail a few month ago, but I don't have a real solution. Regards, HP -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 230 bytes Desc: not available URL: From hannes at yllr.net Fri Mar 18 16:49:56 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Fri, 18 Mar 2011 17:49:56 +0100 Subject: [Vimprobable-users] Input-focus on text fields spawns new window - why? In-Reply-To: References: <20110317233413.0e105d83@workstation> Message-ID: <20110318174956.71e3ce1a@workstation> Hi! Michael Treibton wrote: > 2011/3/17 Hannes Sch?ller : > > Michael Treibton wrote: > >> i'm assuming this is a Javascript change on some sites, but > >> recently ive noticed that clicking in certain elements on a page - > >> noticeably text fields will spawn a new vimprobale window, > >> ?sometimes this opens up the same page, and sometimes opens up a > >> blank page. > > > > I can think of two reasons: > > > > 1. A popup function to show you ads. > > > > 2. Some XMLRPC code (probably a "suggestion" function) trying to > > reference a frame/iframe which doesn't actually exist. > > Let me guess - Vimprobable doesn't provide a solution for either of > these? So you're just guessing or are you basing this assumption on any observations or facts? Hannes P.S. Please send replies to the list only, not to me in copy additionally. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From mtreibton at googlemail.com Sat Mar 19 18:24:33 2011 From: mtreibton at googlemail.com (Michael Treibton) Date: Sat, 19 Mar 2011 18:24:33 +0000 Subject: [Vimprobable-users] Input-focus on text fields spawns new window - why? In-Reply-To: <20110318174956.71e3ce1a@workstation> References: <20110317233413.0e105d83@workstation> <20110318174956.71e3ce1a@workstation> Message-ID: hi! 2011/3/18 Hannes Sch?ller : > Hi! > > Michael Treibton wrote: >> 2011/3/17 Hannes Sch?ller : >> > Michael Treibton wrote: >> >> i'm assuming this is a Javascript change on some sites, but >> >> recently ive noticed that clicking in certain elements on a page - >> >> noticeably text fields will spawn a new vimprobale window, >> >> ?sometimes this opens up the same page, and sometimes opens up a >> >> blank page. >> > >> > I can think of two reasons: >> > >> > 1. A popup function to show you ads. >> > >> > 2. Some XMLRPC code (probably a "suggestion" function) trying to >> > reference a frame/iframe which doesn't actually exist. >> >> Let me guess - Vimprobable doesn't provide a solution for either of >> these? > > So you're just guessing or are you basing this assumption on any > observations or facts? well, i see the problem a lot now when clicking in certain text areas than I used to - so i wonder whats changed. thats all i have to go on. > Hannes > P.S. Please send replies to the list only, not to me in copy > additionally. sorry - but shouldnt your mail user agent help you here? Michael From mtreibton at googlemail.com Sun Mar 20 13:18:45 2011 From: mtreibton at googlemail.com (Michael Treibton) Date: Sun, 20 Mar 2011 13:18:45 +0000 Subject: [Vimprobable-users] state of development? Message-ID: hi! i notice things are quiet with patches - are there any cool new features cooking somewhere? =) Michael From mtreibton at googlemail.com Sun Mar 20 20:00:44 2011 From: mtreibton at googlemail.com (Michael Treibton) Date: Sun, 20 Mar 2011 20:00:44 +0000 Subject: [Vimprobable-users] :set scrollbars off - still shows scrollbar? Message-ID: hi all, on some sites, turning of the scrollbar still shows the scrollbar on the scren - even though i cannot do aything with the scrollbar. why is this? it happens on sites like gmail. is it a bug in vimprobable2? Michael From hpdeifel at gmx.de Fri Mar 25 23:50:14 2011 From: hpdeifel at gmx.de (Hans-Peter Deifel) Date: Sat, 26 Mar 2011 00:50:14 +0100 Subject: [Vimprobable-users] [PATCH 4/5] Make the default search engine configurable In-Reply-To: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> References: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> Message-ID: <1301097015-2831-5-git-send-email-hpdeifel@gmx.de> This introduces the new setting 'defaultsearch' --- config.h | 4 +++- main.c | 11 ++++++++--- 2 files changed, 11 insertions(+), 4 deletions(-) diff --git a/config.h b/config.h index 04af99c..78f32e8 100644 --- a/config.h +++ b/config.h @@ -86,7 +86,8 @@ static Searchengine searchengines[] = { { "w", "https://secure.wikimedia.org/wikipedia/en/w/index.php?title=Special%%3ASearch&search=%s&go=Go" }, { "wd", "https://secure.wikimedia.org/wikipedia/de/w/index.php?title=Special%%3ASearch&search=%s&go=Go" }, }; -static Searchengine *defsearch = &searchengines[0]; + +static char defaultsearch[1024] = "i"; /* command mapping */ Command commands[COMMANDSIZE] = { @@ -176,6 +177,7 @@ static Setting browsersettings[] = { { "sslbgcolor", sslbgcolor, "", FALSE, FALSE, TRUE, TRUE }, { "sslcolor", sslcolor, "", FALSE, FALSE, TRUE, TRUE }, { "acceptlanguage", acceptlanguage, "", FALSE, FALSE, FALSE, FALSE }, + { "defaultsearch", defaultsearch, "", 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 dec0914..131084e 100644 --- a/main.c +++ b/main.c @@ -1129,9 +1129,14 @@ open_arg(const Arg *arg) { strcpy(new, "file://"); memcpy(&new[sizeof("file://") - 1], s, len + 1); } else if (p || !strchr(s, '.')) { /* whitespaces or no dot? */ - p = soup_uri_encode(s, "&"); - new = g_strdup_printf(defsearch->uri, p); - g_free(p); + char *uri; + uri = find_uri_for_searchengine(defaultsearch, searchengines, + LENGTH(searchengines)); + if (uri != NULL) { + char *uri_enc = soup_uri_encode(s, "&"); + new = g_strdup_printf(uri, uri_enc); + g_free(uri_enc); + } } else { /* prepend "http://" */ new = g_malloc(sizeof("http://") + len); strcpy(new, "http://"); -- 1.7.3.4 From hpdeifel at gmx.de Fri Mar 25 23:50:12 2011 From: hpdeifel at gmx.de (Hans-Peter Deifel) Date: Sat, 26 Mar 2011 00:50:12 +0100 Subject: [Vimprobable-users] [PATCH 2/5] Make search engines configurable In-Reply-To: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> References: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> Message-ID: <1301097015-2831-3-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 | 30 +++++++++++---- utilities.c | 114 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ utilities.h | 2 + 3 files changed, 138 insertions(+), 8 deletions(-) diff --git a/main.c b/main.c index 4a1caf8..dec0914 100644 --- a/main.c +++ b/main.c @@ -1103,14 +1103,18 @@ 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 */ + char *uri; + *p = '\0'; + uri = find_uri_for_searchengine(s, searchengines, + LENGTH(searchengines)); + if (uri != NULL) { + char *uri_enc = soup_uri_encode(p+1, "&"); + new = g_strdup_printf(uri, uri_enc); + g_free(uri_enc); + } + *p = ' '; + } if (!new) { if (len > 3 && strstr(s, "://")) { /* valid url? */ p = new = g_malloc(len + 1); @@ -2312,6 +2316,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 +2377,15 @@ main(int argc, char *argv[]) { g_free(configfile); } + /* read searchengines. */ + searchengines_file = g_strdup_printf(SEARCHENGINES_STORAGE_FILENAME); + if (read_searchengines(searchengines_file) < -1) { + a.i = Error; + a.s = g_strdup_printf("Error in searchengines file '%s'", searchengines_file); + echo(&a); + } + 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..7e8fe7e 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,116 @@ count_list(Listelement *elementlist) return n; } + +/* 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 percent_s_count == 1; +} + +/* return -1 if the file could not be opened, -2 if it contains malformed lines + * and 0 on success */ +int read_searchengines(const char *filename) +{ + FILE *file; + char buffer[BUFFERSIZE]; + char *name_ptr, *url_ptr; + gboolean found_malformed_lines = FALSE, + line_too_long = FALSE; + int length; + Searchengine *new; + + file = fopen(filename, "r"); + if (file == NULL) + return -1; + + while (fgets(buffer, BUFFERSIZE, file)){ + /* ignore lines longer then BUFFERSIZE */ + length = strlen(buffer); + if (length == 0 || buffer[length-1] != '\n') { + line_too_long = TRUE; + found_malformed_lines = TRUE; + continue; + } + + /* continuation of long line */ + if (line_too_long) { + line_too_long = FALSE; + continue; + } + + name_ptr = strtok(buffer, " \t\n"); + url_ptr = strtok(NULL, "\n"); + + if (name_ptr == NULL || url_ptr == NULL + || !sanity_check_search_url(url_ptr)) { + found_malformed_lines = TRUE; + continue; + } + + new = malloc(sizeof(Searchengine)); + new->handle = g_strdup(name_ptr); + new->uri = g_strdup(url_ptr); + + dynamic_searchengines = g_list_prepend(dynamic_searchengines, new); + } + + /* Is this really necessary? -- It guarantees that it's possible to + * overwrite previously defined searchengines and it's only O(n), so it + * shouldn't do much harm... */ + dynamic_searchengines = g_list_reverse(dynamic_searchengines); + + fclose(file); + + return found_malformed_lines ? -2 : 0; +} + +/* find a searchengine with a given handle and return it's URI or NULL if + * nothing is found. + * The returned string is internal and must not be freed or modified. */ +char *find_uri_for_searchengine(char *handle, + Searchengine *static_searchengines, int n) +{ + int i; + GList *l; + + /* If dynamic searchengines exist, we can use them */ + 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; + } + } + } + + /* try the static searchengines as fallback */ + for (i = 0; i < n; i++) { + if (!strcmp(static_searchengines[i].handle, handle)) { + return static_searchengines[i].uri; + } + } + + return NULL; +} diff --git a/utilities.h b/utilities.h index 261d213..983859f 100644 --- a/utilities.h +++ b/utilities.h @@ -30,3 +30,5 @@ 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); +char *find_uri_for_searchengine(char *handle, Searchengine *static_searchengines, int n); +int read_searchengines(const char *filename); -- 1.7.3.4 From hpdeifel at gmx.de Fri Mar 25 23:50:10 2011 From: hpdeifel at gmx.de (Hans-Peter Deifel) Date: Sat, 26 Mar 2011 00:50:10 +0100 Subject: [Vimprobable-users] [PATCH 0/5] Configurable search engines Message-ID: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> Hi all, This patch series introduces a new configuration file for search engines, that can contain lines such as: ddg https://duckduckgo.com/?q=%s to add 'ddg' to the search engines defined in config.h. Also, the new setting 'defaultsearch' controls which search engine to use. Regards, HP Hans-Peter Deifel (5): Define storage location for searchengines Make search engines configurable Mention search engines in the man page Make the default search engine configurable Add the 'defaultsearch' setting to the manpage config.h | 4 +- main.c | 41 ++++++++++++++----- utilities.c | 114 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ utilities.h | 2 + vimprobable.h | 3 + vimprobable2.1 | 32 +++++++++++++++ vimprobablerc.1 | 3 + 7 files changed, 187 insertions(+), 12 deletions(-) -- 1.7.3.4 From hpdeifel at gmx.de Fri Mar 25 23:50:13 2011 From: hpdeifel at gmx.de (Hans-Peter Deifel) Date: Sat, 26 Mar 2011 00:50:13 +0100 Subject: [Vimprobable-users] [PATCH 3/5] Mention search engines in the man page In-Reply-To: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> References: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> Message-ID: <1301097015-2831-4-git-send-email-hpdeifel@gmx.de> --- vimprobable2.1 | 32 ++++++++++++++++++++++++++++++++ 1 files changed, 32 insertions(+), 0 deletions(-) diff --git a/vimprobable2.1 b/vimprobable2.1 index 71f2c49..faf15e7 100644 --- a/vimprobable2.1 +++ b/vimprobable2.1 @@ -265,6 +265,36 @@ Store current URI as quickmark 4 q4 Recall quickmark 4 +.SH SEARCHENGINES + +Vimprobable interprets URLs consisting of multiple words as +search queries, where the first word specifies the search engine. Some +search engines are already predefined in config.h, but you can always +add your own in +.I $HOME/.config/vimprobable/searchengines. +.PP +E.g. if this file contains the line + +.RS +ex http://www.example.com/search?q=%s +.RE + +Vimprobable will expand the command + +.RS +:open ex foo bar +.RE + +into + +.RS +:open http://www.example.com/search?q=foo+bar +.RE + +Note, that the +.I %s +has been replaced by the search query. + .SH FILES Please make sure you create these files before running the browser. @@ -275,6 +305,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 hpdeifel at gmx.de Fri Mar 25 23:50:11 2011 From: hpdeifel at gmx.de (Hans-Peter Deifel) Date: Sat, 26 Mar 2011 00:50:11 +0100 Subject: [Vimprobable-users] [PATCH 1/5] Define storage location for searchengines In-Reply-To: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> References: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> Message-ID: <1301097015-2831-2-git-send-email-hpdeifel@gmx.de> --- vimprobable.h | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/vimprobable.h b/vimprobable.h index 72fe819..9732bc9 100644 --- a/vimprobable.h +++ b/vimprobable.h @@ -168,6 +168,9 @@ typedef struct { #define HISTORY_STORAGE_FILENAME "%s/.config/vimprobable/history", getenv("HOME") #define CLOSED_URL_FILENAME "%s/.config/vimprobable/closed", getenv("HOME") +/* searchengines */ +#define SEARCHENGINES_STORAGE_FILENAME "%s/.config/vimprobable/searchengines", getenv("HOME") + /* Command size */ #define COMMANDSIZE 1024 -- 1.7.3.4 From hpdeifel at gmx.de Fri Mar 25 23:50:15 2011 From: hpdeifel at gmx.de (Hans-Peter Deifel) Date: Sat, 26 Mar 2011 00:50:15 +0100 Subject: [Vimprobable-users] [PATCH 5/5] Add the 'defaultsearch' setting to the manpage In-Reply-To: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> References: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> Message-ID: <1301097015-2831-6-git-send-email-hpdeifel@gmx.de> --- vimprobablerc.1 | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/vimprobablerc.1 b/vimprobablerc.1 index cef3adc..f22013a 100644 --- a/vimprobablerc.1 +++ b/vimprobablerc.1 @@ -94,6 +94,9 @@ Replace the default encoding .IP defaultfont=default-font-family Replace the default font family +.IP defaultsearch=searchengine +Replace the default search engine + .IP fontsize=integer Replace the default fontsize -- 1.7.3.4 From thomas at xteddy.org Sat Mar 26 00:05:22 2011 From: thomas at xteddy.org (Thomas Adam) Date: Sat, 26 Mar 2011 00:05:22 +0000 Subject: [Vimprobable-users] [PATCH 2/5] Make search engines configurable In-Reply-To: <1301097015-2831-3-git-send-email-hpdeifel@gmx.de> References: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> <1301097015-2831-3-git-send-email-hpdeifel@gmx.de> Message-ID: <20110326000520.GA5651@debian.ttn6tadam> Hello -- I don't have the time to review this properly, but some very quick observations... On Sat, Mar 26, 2011 at 12:50:12AM +0100, Hans-Peter Deifel wrote: > + if (read_searchengines(searchengines_file) < -1) { Less than -1? If that's true, I'd rather see an enum or a #define for these values, with a justification otherwise from you as to what they mean. I *hate* random non-zero return values returned in this way. > +static GList *dynamic_searchengines = NULL; We already define a SearchEngines structure, which should probably be reworked to include a member for this. > gboolean read_rcfile(const char *config) > { > @@ -639,3 +640,116 @@ count_list(Listelement *elementlist) > > return n; > } > + > +/* 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 percent_s_count == 1; > +} Glib has routines for this -- please use them, rather than reinventing the wheel. > +/* return -1 if the file could not be opened, -2 if it contains malformed lines > + * and 0 on success */ > +int read_searchengines(const char *filename) Const -- good. > + FILE *file; > + char buffer[BUFFERSIZE]; > + char *name_ptr, *url_ptr; > + gboolean found_malformed_lines = FALSE, > + line_too_long = FALSE; Don't do this, do: gboolean foo; gboolean bar; Also set their default values preferrably not here. > + int length; > + Searchengine *new; > + > + file = fopen(filename, "r"); > + if (file == NULL) > + return -1; See "man access" and in particular the patch I wrote for looking for config files via -c as a result. > + while (fgets(buffer, BUFFERSIZE, file)){ > + /* ignore lines longer then BUFFERSIZE */ > + length = strlen(buffer); > + if (length == 0 || buffer[length-1] != '\n') { > + line_too_long = TRUE; > + found_malformed_lines = TRUE; > + continue; > + } No warning? No nothing if the line is too long? Why the limit in the first place? > + /* continuation of long line */ > + if (line_too_long) { > + line_too_long = FALSE; > + continue; > + } Gah. > + name_ptr = strtok(buffer, " \t\n"); > + url_ptr = strtok(NULL, "\n"); Use more glib, please. strtok is not portable. > + if (name_ptr == NULL || url_ptr == NULL > + || !sanity_check_search_url(url_ptr)) { > + found_malformed_lines = TRUE; > + continue; > + } > + new = malloc(sizeof(Searchengine)); Check for new == NULL. > + new->handle = g_strdup(name_ptr); > + new->uri = g_strdup(url_ptr); > + > + dynamic_searchengines = g_list_prepend(dynamic_searchengines, new); > + } > + > + /* Is this really necessary? -- It guarantees that it's possible to > + * overwrite previously defined searchengines and it's only O(n), so it > + * shouldn't do much harm... */ > + dynamic_searchengines = g_list_reverse(dynamic_searchengines); No, this is a ticking time-bomb for large sets of defined engines. > + fclose(file); > + > + return found_malformed_lines ? -2 : 0; Again see previous enum/#define comment earlier. > + > +/* find a searchengine with a given handle and return it's URI or NULL if s/it\'s/its/ > + * nothing is found. > + * The returned string is internal and must not be freed or modified. */ > +char *find_uri_for_searchengine(char *handle, > + Searchengine *static_searchengines, int n) > +{ > + int i; > + GList *l; > + > + /* If dynamic searchengines exist, we can use them */ > + 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; > + } > + } > + } I don't like this -- glib defines ways for free()ing data members from a list anyway. Sorry for the terseness, no time. -- Thomas Adam -- "Deep in my heart I wish I was wrong. But deep in my heart I know I am not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.) From hpdeifel at gmx.de Sat Mar 26 00:08:13 2011 From: hpdeifel at gmx.de (Hans-Peter Deifel) Date: Sat, 26 Mar 2011 01:08:13 +0100 Subject: [Vimprobable-users] :set scrollbars off - still shows scrollbar? In-Reply-To: References: Message-ID: <20110326000812.GA2958@deepsilver> On 20:00 Sun 20 Mar , Michael Treibton wrote: > hi all, > > on some sites, turning of the scrollbar still shows the scrollbar on > the scren - even though i cannot do aything with the scrollbar. > > why is this? it happens on sites like gmail. Seems to be caused by the CSS property 'overflow-y', which is set to 'scroll' on some (google) pages. > > is it a bug in vimprobable2? Rather in webkit. Regards, HP -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 230 bytes Desc: not available URL: From thomas at xteddy.org Sat Mar 26 00:31:06 2011 From: thomas at xteddy.org (Thomas Adam) Date: Sat, 26 Mar 2011 00:31:06 +0000 Subject: [Vimprobable-users] [PATCH 5/5] Add the 'defaultsearch' setting to the manpage In-Reply-To: <1301097015-2831-6-git-send-email-hpdeifel@gmx.de> References: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> <1301097015-2831-6-git-send-email-hpdeifel@gmx.de> Message-ID: <20110326003104.GB5651@debian.ttn6tadam> On Sat, Mar 26, 2011 at 12:50:15AM +0100, Hans-Peter Deifel wrote: > --- > vimprobablerc.1 | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/vimprobablerc.1 b/vimprobablerc.1 > index cef3adc..f22013a 100644 > --- a/vimprobablerc.1 > +++ b/vimprobablerc.1 > @@ -94,6 +94,9 @@ Replace the default encoding > .IP defaultfont=default-font-family > Replace the default font family > > +.IP defaultsearch=searchengine > +Replace the default search engine > + Oh, quickly, there should be a way to list the search engines defined, and also which one is the default. Very easy to do with your patch series. Consider adding this. -- Thomas Adam -- "Deep in my heart I wish I was wrong. But deep in my heart I know I am not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.) From thomas at xteddy.org Sat Mar 26 00:36:00 2011 From: thomas at xteddy.org (Thomas Adam) Date: Sat, 26 Mar 2011 00:36:00 +0000 Subject: [Vimprobable-users] [PATCH 3/5] Mention search engines in the man page In-Reply-To: <1301097015-2831-4-git-send-email-hpdeifel@gmx.de> References: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> <1301097015-2831-4-git-send-email-hpdeifel@gmx.de> Message-ID: <20110326003559.GC5651@debian.ttn6tadam> On Sat, Mar 26, 2011 at 12:50:13AM +0100, Hans-Peter Deifel wrote: > +.SH SEARCHENGINES > + > +Vimprobable interprets URLs consisting of multiple words as > +search queries, where the first word specifies the search engine. Some > +search engines are already predefined in config.h, but you can always This needs toning down. It's more or less like: Vimprobable will parse anything it doesn't recognise as a URL as matching against a search engine. > +add your own in > +.I $HOME/.config/vimprobable/searchengines. > +.PP > +E.g. if this file contains the line > + > +.RS > +ex http://www.example.com/search?q=%s > +.RE > + > +Vimprobable will expand the command > + > +.RS > +:open ex foo bar > +.RE This should be done *ONLY* via Vimprobable -- what if we decide to change the format on-disk? No -- such documentation as stated is dangerous. > +into > + > +.RS > +:open http://www.example.com/search?q=foo+bar > +.RE > + > +Note, that the > +.I %s > +has been replaced by the search query. Hmm. The more I think about this, the more I think searchengines are just a special form a bookmarking and we need not distinguish between the two. -- Thomas Adam -- "Deep in my heart I wish I was wrong. But deep in my heart I know I am not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.) From thomas at xteddy.org Sat Mar 26 00:40:32 2011 From: thomas at xteddy.org (Thomas Adam) Date: Sat, 26 Mar 2011 00:40:32 +0000 Subject: [Vimprobable-users] [PATCH 0/5] Configurable search engines In-Reply-To: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> References: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> Message-ID: <20110326004030.GD5651@debian.ttn6tadam> On Sat, Mar 26, 2011 at 12:50:10AM +0100, Hans-Peter Deifel wrote: > Hi all, > > This patch series introduces a new configuration file for search engines, > that can contain lines such as: > > ddg https://duckduckgo.com/?q=%s > > to add 'ddg' to the search engines defined in config.h. This is probably better than the series I have sat here in Git, to be honest, although see comments where necesary. Before this might be considered worthy, I'd like to rework a lot of what's mentiond by me before it's merged. Overall though, good job, Hans-Peter -- it looks OK. -- Thomas Adam -- "Deep in my heart I wish I was wrong. But deep in my heart I know I am not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.) From hannes at yllr.net Sat Mar 26 09:18:39 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 26 Mar 2011 10:18:39 +0100 Subject: [Vimprobable-users] [PATCH 2/5] Make search engines configurable In-Reply-To: <1301097015-2831-3-git-send-email-hpdeifel@gmx.de> References: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> <1301097015-2831-3-git-send-email-hpdeifel@gmx.de> Message-ID: <20110326101839.0edc9258@workstation> Hi! Hans-Peter Deifel wrote: > + while (fgets(buffer, BUFFERSIZE, file)){ > + /* ignore lines longer then BUFFERSIZE */ > + length = strlen(buffer); > + if (length == 0 || buffer[length-1] != '\n') { > + line_too_long = TRUE; > + found_malformed_lines = TRUE; > + continue; > + } > + > + /* continuation of long line */ > + if (line_too_long) { > + line_too_long = FALSE; > + continue; > + } This seems like a rather cludgy workaround -- most importantly, if a line is longer than 2*BUFFERSIZE, the last part *will* be processed, probably resulting in an undefined state. > +char *find_uri_for_searchengine(char *handle, > + Searchengine *static_searchengines, int n) This whole function (and the related lookup performed in it) could be avoided by simply writing the "dynamically defined" search engines (i.e. the one from the config file) to the existing searchengines structure. 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 Sat Mar 26 09:23:07 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 26 Mar 2011 10:23:07 +0100 Subject: [Vimprobable-users] [PATCH 2/5] Make search engines configurable In-Reply-To: <20110326000520.GA5651@debian.ttn6tadam> References: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> <1301097015-2831-3-git-send-email-hpdeifel@gmx.de> <20110326000520.GA5651@debian.ttn6tadam> Message-ID: <20110326102307.2b06524f@workstation> Hi! Thomas Adam wrote: > On Sat, Mar 26, 2011 at 12:50:12AM +0100, Hans-Peter Deifel wrote: > > + if (read_searchengines(searchengines_file) < -1) { OK with me. > > gboolean read_rcfile(const char *config) > > { > > @@ -639,3 +640,116 @@ count_list(Listelement *elementlist) > > > > return n; > > } > > + > > +/* 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 percent_s_count == 1; > > +} OK with me. > > + FILE *file; > > + char buffer[BUFFERSIZE]; > > + char *name_ptr, *url_ptr; > > + gboolean found_malformed_lines = FALSE, > > + line_too_long = FALSE; > > Don't do this, do: > > gboolean foo; > gboolean bar; > > Also set their default values preferrably not here. I disagree. HP did it exactly right. > > + name_ptr = strtok(buffer, " \t\n"); > > + url_ptr = strtok(NULL, "\n"); > > Use more glib, please. strtok is not portable. Not less portable than glib. > > + * nothing is found. > > + * The returned string is internal and must not be freed or > > modified. */ +char *find_uri_for_searchengine(char *handle, > > + Searchengine *static_searchengines, int n) > > +{ > > + int i; > > + GList *l; > > + > > + /* If dynamic searchengines exist, we can use them */ > > + 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; > > + } > > + } > > + } > > I don't like this -- glib defines ways for free()ing data members > from a list anyway. What does this snippet have to do with freeing data members from a list? It's about identifying the search URL pattern to use for the given shortcut. See my comment about this function. 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 Sat Mar 26 09:25:30 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 26 Mar 2011 10:25:30 +0100 Subject: [Vimprobable-users] [PATCH 3/5] Mention search engines in the man page In-Reply-To: <1301097015-2831-4-git-send-email-hpdeifel@gmx.de> References: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> <1301097015-2831-4-git-send-email-hpdeifel@gmx.de> Message-ID: <20110326102530.69490abb@workstation> Hi, please add that searchengine shortcuts defined in config.h can be overwritten in the config file. 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 Sat Mar 26 09:29:20 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 26 Mar 2011 10:29:20 +0100 Subject: [Vimprobable-users] [PATCH 4/5] Make the default search engine configurable In-Reply-To: <1301097015-2831-5-git-send-email-hpdeifel@gmx.de> References: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> <1301097015-2831-5-git-send-email-hpdeifel@gmx.de> Message-ID: <20110326102920.71dd6011@workstation> Hi! Hans-Peter Deifel wrote: > + char *uri; Please put all declarations at the beginning of the respective function. 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 Sat Mar 26 09:31:14 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 26 Mar 2011 10:31:14 +0100 Subject: [Vimprobable-users] [PATCH 5/5] Add the 'defaultsearch' setting to the manpage In-Reply-To: <1301097015-2831-6-git-send-email-hpdeifel@gmx.de> References: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> <1301097015-2831-6-git-send-email-hpdeifel@gmx.de> Message-ID: <20110326103114.18f55e2f@workstation> Hi! Hans-Peter Deifel wrote: > +.IP defaultsearch=searchengine > +Replace the default search engine This needs elaborating, specifically, that this needs to be set to a valid searchengine shortcut key. 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 Sat Mar 26 09:34:36 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 26 Mar 2011 10:34:36 +0100 Subject: [Vimprobable-users] [PATCH 4/5] Make the default search engine configurable In-Reply-To: <1301097015-2831-5-git-send-email-hpdeifel@gmx.de> References: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> <1301097015-2831-5-git-send-email-hpdeifel@gmx.de> Message-ID: <20110326103436.570e7daf@workstation> Hans-Peter Deifel wrote: > +static char defaultsearch[1024] = "i"; This reminds me - I should add a check not to overflow user definable variables. 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 Sat Mar 26 09:38:17 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 26 Mar 2011 10:38:17 +0100 Subject: [Vimprobable-users] [PATCH 0/5] Configurable search engines In-Reply-To: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> References: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> Message-ID: <20110326103817.3709b5dc@workstation> Hi! Hans-Peter Deifel wrote: > This patch series introduces a new configuration file for search > engines, that can contain lines such as: > > ddg https://duckduckgo.com/?q=%s > > to add 'ddg' to the search engines defined in config.h. > > Also, the new setting 'defaultsearch' controls which search engine to > use. I think this would be extremely useful. From the architectural point of view, I haev only one comment (also noted in one code comment): Currently, you're defining a new list of "dynamic" searchengines and then hierarchically check first that and in the case of no match, check the default list. This works, but it's not very elegant. Please have a look at the keybinding handling. There, we define a default list in keymap.h and when a new keybinding is defined, it is either added to that list or the existing binding for that combination of keys is overwritten. That way, only one lookup is necessary as all instances are stored in a single list. I think the same principle should be applied to the searchengine handling. Other than that, this looks very good! Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From hpdeifel at gmx.de Sat Mar 26 10:08:15 2011 From: hpdeifel at gmx.de (Hans-Peter Deifel) Date: Sat, 26 Mar 2011 11:08:15 +0100 Subject: [Vimprobable-users] [PATCH 2/5] Make search engines configurable In-Reply-To: <20110326000520.GA5651@debian.ttn6tadam> References: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> <1301097015-2831-3-git-send-email-hpdeifel@gmx.de> <20110326000520.GA5651@debian.ttn6tadam> Message-ID: <20110326100815.GA7317@deepsilver> Hi, Thanks for your comments. There is no need for hurry, this patch will likely need some discussion. On 00:05 Sat 26 Mar , Thomas Adam wrote: > Hello -- > > I don't have the time to review this properly, but some very quick > observations... > > On Sat, Mar 26, 2011 at 12:50:12AM +0100, Hans-Peter Deifel wrote: > > + if (read_searchengines(searchengines_file) < -1) { > > Less than -1? If that's true, I'd rather see an enum or a #define for these > values, with a justification otherwise from you as to what they mean. I > *hate* random non-zero return values returned in this way. The value is explained in a comment at read_searchengines, but it should probably be an enum or similar. Will fix. > > +static GList *dynamic_searchengines = NULL; > > We already define a SearchEngines structure, which should probably be > reworked to include a member for this. Hannes' comment regarding the keybindings seems to be a reasonable solution. > > gboolean read_rcfile(const char *config) > > { > > @@ -639,3 +640,116 @@ count_list(Listelement *elementlist) > > > > return n; > > } > > + > > +/* 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 percent_s_count == 1; > > +} > > Glib has routines for this -- please use them, rather than reinventing the > wheel. > I didn't find such a routine. > > +/* return -1 if the file could not be opened, -2 if it contains malformed lines > > + * and 0 on success */ > > +int read_searchengines(const char *filename) > > Const -- good. > > > + FILE *file; > > + char buffer[BUFFERSIZE]; > > + char *name_ptr, *url_ptr; > > + gboolean found_malformed_lines = FALSE, > > + line_too_long = FALSE; > > Don't do this, do: > > gboolean foo; > gboolean bar; > > Also set their default values preferrably not here. See Hannes' comment. > > + int length; > > + Searchengine *new; > > + > > + file = fopen(filename, "r"); > > + if (file == NULL) > > + return -1; > > See "man access" and in particular the patch I wrote for looking for config > files via -c as a result. Since the searchengines file cannot be specified on the command-line, there shouldn't be any message if it doesn't exist. Just as it is the case with every other file, vimprobable uses. Now I differentiate between "fopen failed" and "syntactic errors in the file", and report only the latter. I could of course use "file does not _exist_(nothing about it's readability)" vs "fopen failed _or_ syntactic errors in the file". I don't know which is better, but I can certainly adopt the latter scheme, if required. Or maybe use finer grained error conditions in the first place. > > + while (fgets(buffer, BUFFERSIZE, file)){ > > + /* ignore lines longer then BUFFERSIZE */ > > + length = strlen(buffer); > > + if (length == 0 || buffer[length-1] != '\n') { > > + line_too_long = TRUE; > > + found_malformed_lines = TRUE; > > + continue; > > + } > > No warning? No nothing if the line is too long? Why the limit in the first > place? found_malformed_lines is set to true, which is considered for the return value. > > + /* continuation of long line */ > > + if (line_too_long) { > > + line_too_long = FALSE; > > + continue; > > + } > > Gah. While it could be written in a less goto-y style, I see nothing wrong here. > > + name_ptr = strtok(buffer, " \t\n"); > > + url_ptr = strtok(NULL, "\n"); > > Use more glib, please. strtok is not portable. I see g_strsplit, which allocates a new array for it's return value. > > + if (name_ptr == NULL || url_ptr == NULL > > + || !sanity_check_search_url(url_ptr)) { > > + found_malformed_lines = TRUE; > > + continue; > > + } > > + new = malloc(sizeof(Searchengine)); > > Check for new == NULL. > Will do. > > + new->handle = g_strdup(name_ptr); > > + new->uri = g_strdup(url_ptr); > > + > > + dynamic_searchengines = g_list_prepend(dynamic_searchengines, new); > > + } > > + > > + /* Is this really necessary? -- It guarantees that it's possible to > > + * overwrite previously defined searchengines and it's only O(n), so it > > + * shouldn't do much harm... */ > > + dynamic_searchengines = g_list_reverse(dynamic_searchengines); > > No, this is a ticking time-bomb for large sets of defined engines. Nope. I did benchmarks with 1000000 randomly generated searchengines and it did not get slow. Remember, that GList is a doubly linked list and therefore extremely easy to reverse. Also, the whole function is inherently IO-bound. The alternative would be either g_list_append instead of -prepend, which is of course O(n^2), or some ugly hack, like keeping track of the last element, or searching the list in reverse. -- IMHO not worth it. > > + fclose(file); > > + > > + return found_malformed_lines ? -2 : 0; > > Again see previous enum/#define comment earlier. > > > + > > +/* find a searchengine with a given handle and return it's URI or NULL if > > s/it\'s/its/ > > > + * nothing is found. > > + * The returned string is internal and must not be freed or modified. */ > > +char *find_uri_for_searchengine(char *handle, > > + Searchengine *static_searchengines, int n) > > +{ > > + int i; > > + GList *l; > > + > > + /* If dynamic searchengines exist, we can use them */ > > + 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; > > + } > > + } > > + } > > I don't like this -- glib defines ways for free()ing data members from a > list anyway. We could of course strdup the string before returning it. Again, thanks for the feedback. Regards, HP -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 230 bytes Desc: not available URL: From hpdeifel at gmx.de Sat Mar 26 10:16:26 2011 From: hpdeifel at gmx.de (Hans-Peter Deifel) Date: Sat, 26 Mar 2011 11:16:26 +0100 Subject: [Vimprobable-users] [PATCH 2/5] Make search engines configurable In-Reply-To: <20110326101839.0edc9258@workstation> References: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> <1301097015-2831-3-git-send-email-hpdeifel@gmx.de> <20110326101839.0edc9258@workstation> Message-ID: <20110326101626.GB7317@deepsilver> Hi, On 10:18 Sat 26 Mar , Hannes Sch?ller wrote: > Hi! > > Hans-Peter Deifel wrote: > > + while (fgets(buffer, BUFFERSIZE, file)){ > > + /* ignore lines longer then BUFFERSIZE */ > > + length = strlen(buffer); > > + if (length == 0 || buffer[length-1] != '\n') { > > + line_too_long = TRUE; > > + found_malformed_lines = TRUE; > > + continue; > > + } > > + > > + /* continuation of long line */ > > + if (line_too_long) { > > + line_too_long = FALSE; > > + continue; > > + } > > This seems like a rather cludgy workaround -- most importantly, if a > line is longer than 2*BUFFERSIZE, the last part *will* be processed, > probably resulting in an undefined state. I wanted to keep the buffer stack-allocated, otherwise I could have just used g_string_append or something similar. If the line is N chars long, It will be caught N/(BUFFERSIZE-1) times in the first if, and only the last N%(BUFFERSIZE-1) chars will be handled by the second. > > +char *find_uri_for_searchengine(char *handle, > > + Searchengine *static_searchengines, int n) > > This whole function (and the related lookup performed in it) could be > avoided by simply writing the "dynamically defined" search engines > (i.e. the one from the config file) to the existing searchengines > structure. I don't know if its good to use the existing searchengines pointer for that, but the approach used for the keybindings seems reasonable to me. It should be other way round, the static searchengines will be appended to the dynamic ones. I would also like to keep this function, if just to abstract away the lookup procedure. Maybe with a different signature. Regards, HP -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 230 bytes Desc: not available URL: From hannes at yllr.net Sat Mar 26 10:22:52 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 26 Mar 2011 11:22:52 +0100 Subject: [Vimprobable-users] [PATCH 2/5] Make search engines configurable In-Reply-To: <20110326101626.GB7317@deepsilver> References: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> <1301097015-2831-3-git-send-email-hpdeifel@gmx.de> <20110326101839.0edc9258@workstation> <20110326101626.GB7317@deepsilver> Message-ID: <20110326112252.73a2b2e6@workstation> Hi! Hans-Peter Deifel wrote: > On 10:18 Sat 26 Mar , Hannes Sch?ller wrote: > > Hi! > > > > Hans-Peter Deifel wrote: > > > + while (fgets(buffer, BUFFERSIZE, file)){ > > > + /* ignore lines longer then BUFFERSIZE */ > > > + length = strlen(buffer); > > > + if (length == 0 || buffer[length-1] != '\n') { > > > + line_too_long = TRUE; > > > + found_malformed_lines = TRUE; > > > + continue; > > > + } > > > + > > > + /* continuation of long line */ > > > + if (line_too_long) { > > > + line_too_long = FALSE; > > > + continue; > > > + } > > > > This seems like a rather cludgy workaround -- most importantly, if a > > line is longer than 2*BUFFERSIZE, the last part *will* be processed, > > probably resulting in an undefined state. > > I wanted to keep the buffer stack-allocated, otherwise I could have > just used g_string_append or something similar. > > If the line is N chars long, It will be caught N/(BUFFERSIZE-1) times > in the first if, and only the last N%(BUFFERSIZE-1) chars will be > handled by the second. Ah, sorry, I misread the code. All the initial non-newline terminated string will be caught by the first check, yes. > > > +char *find_uri_for_searchengine(char *handle, > > > + Searchengine *static_searchengines, int n) > > > > This whole function (and the related lookup performed in it) could > > be avoided by simply writing the "dynamically defined" search > > engines (i.e. the one from the config file) to the existing > > searchengines structure. > > I don't know if its good to use the existing searchengines pointer for > that, but the approach used for the keybindings seems reasonable to > me. It should be other way round, the static searchengines will be > appended to the dynamic ones. > > I would also like to keep this function, if just to abstract away the > lookup procedure. Maybe with a different signature. Fair enough. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From hpdeifel at gmx.de Sat Mar 26 10:25:01 2011 From: hpdeifel at gmx.de (Hans-Peter Deifel) Date: Sat, 26 Mar 2011 11:25:01 +0100 Subject: [Vimprobable-users] [PATCH 3/5] Mention search engines in the man page In-Reply-To: <20110326003559.GC5651@debian.ttn6tadam> References: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> <1301097015-2831-4-git-send-email-hpdeifel@gmx.de> <20110326003559.GC5651@debian.ttn6tadam> Message-ID: <20110326102501.GC7317@deepsilver> On 00:36 Sat 26 Mar , Thomas Adam wrote: > On Sat, Mar 26, 2011 at 12:50:13AM +0100, Hans-Peter Deifel wrote: > > +.SH SEARCHENGINES > > + > > +Vimprobable interprets URLs consisting of multiple words as > > +search queries, where the first word specifies the search engine. Some > > +search engines are already predefined in config.h, but you can always > > This needs toning down. It's more or less like: > > Vimprobable will parse anything it doesn't recognise as a URL as matching > against a search engine. I will try to rephrase the text > > +add your own in > > +.I $HOME/.config/vimprobable/searchengines. > > +.PP > > +E.g. if this file contains the line > > + > > +.RS > > +ex http://www.example.com/search?q=%s > > +.RE > > + > > +Vimprobable will expand the command > > + > > +.RS > > +:open ex foo bar > > +.RE > > This should be done *ONLY* via Vimprobable -- what if we decide to change > the format on-disk? No -- such documentation as stated is dangerous. I agree that documenting the config file by example is rather poor, I will try to rephrase that, too. But the searchengines file is (currently) meant to be edited by the user, therefore its format must be documented somewhere. > > +into > > + > > +.RS > > +:open http://www.example.com/search?q=foo+bar > > +.RE > > + > > +Note, that the > > +.I %s > > +has been replaced by the search query. > > Hmm. The more I think about this, the more I think searchengines are just a > special form a bookmarking and we need not distinguish between the two. I don't think we should strive for conceptual pureness here :) Sometimes Worse Is Better(TM). Regards, HP -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 230 bytes Desc: not available URL: From hpdeifel at gmx.de Sat Mar 26 10:25:29 2011 From: hpdeifel at gmx.de (Hans-Peter Deifel) Date: Sat, 26 Mar 2011 11:25:29 +0100 Subject: [Vimprobable-users] [PATCH 3/5] Mention search engines in the man page In-Reply-To: <20110326102530.69490abb@workstation> References: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> <1301097015-2831-4-git-send-email-hpdeifel@gmx.de> <20110326102530.69490abb@workstation> Message-ID: <20110326102529.GD7317@deepsilver> On 10:25 Sat 26 Mar , Hannes Sch?ller wrote: > Hi, > > please add that searchengine shortcuts defined in config.h can be > overwritten in the config file. Will do. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 230 bytes Desc: not available URL: From hpdeifel at gmx.de Sat Mar 26 10:26:02 2011 From: hpdeifel at gmx.de (Hans-Peter Deifel) Date: Sat, 26 Mar 2011 11:26:02 +0100 Subject: [Vimprobable-users] [PATCH 4/5] Make the default search engine configurable In-Reply-To: <20110326102920.71dd6011@workstation> References: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> <1301097015-2831-5-git-send-email-hpdeifel@gmx.de> <20110326102920.71dd6011@workstation> Message-ID: <20110326102601.GE7317@deepsilver> On 10:29 Sat 26 Mar , Hannes Sch?ller wrote: > Hi! > > Hans-Peter Deifel wrote: > > + char *uri; > > Please put all declarations at the beginning of the respective function. Will do. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 230 bytes Desc: not available URL: From hpdeifel at gmx.de Sat Mar 26 10:28:07 2011 From: hpdeifel at gmx.de (Hans-Peter Deifel) Date: Sat, 26 Mar 2011 11:28:07 +0100 Subject: [Vimprobable-users] [PATCH 5/5] Add the 'defaultsearch' setting to the manpage In-Reply-To: <20110326003104.GB5651@debian.ttn6tadam> References: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> <1301097015-2831-6-git-send-email-hpdeifel@gmx.de> <20110326003104.GB5651@debian.ttn6tadam> Message-ID: <20110326102807.GF7317@deepsilver> On 00:31 Sat 26 Mar , Thomas Adam wrote: > On Sat, Mar 26, 2011 at 12:50:15AM +0100, Hans-Peter Deifel wrote: > > --- > > vimprobablerc.1 | 3 +++ > > 1 files changed, 3 insertions(+), 0 deletions(-) > > > > diff --git a/vimprobablerc.1 b/vimprobablerc.1 > > index cef3adc..f22013a 100644 > > --- a/vimprobablerc.1 > > +++ b/vimprobablerc.1 > > @@ -94,6 +94,9 @@ Replace the default encoding > > .IP defaultfont=default-font-family > > Replace the default font family > > > > +.IP defaultsearch=searchengine > > +Replace the default search engine > > + > > Oh, quickly, there should be a way to list the search engines defined, and > also which one is the default. Very easy to do with your patch series. > > Consider adding this. I will consider it, after the base patch series is applied. Regards, HP -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 230 bytes Desc: not available URL: From hpdeifel at gmx.de Sat Mar 26 10:29:00 2011 From: hpdeifel at gmx.de (Hans-Peter Deifel) Date: Sat, 26 Mar 2011 11:29:00 +0100 Subject: [Vimprobable-users] [PATCH 5/5] Add the 'defaultsearch' setting to the manpage In-Reply-To: <20110326103114.18f55e2f@workstation> References: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> <1301097015-2831-6-git-send-email-hpdeifel@gmx.de> <20110326103114.18f55e2f@workstation> Message-ID: <20110326102859.GG7317@deepsilver> On 10:31 Sat 26 Mar , Hannes Sch?ller wrote: > Hi! > > Hans-Peter Deifel wrote: > > +.IP defaultsearch=searchengine > > +Replace the default search engine > > This needs elaborating, specifically, that this needs to be set to a > valid searchengine shortcut key. Yep. Will do. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 230 bytes Desc: not available URL: From hannes at yllr.net Sat Mar 26 10:28:33 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 26 Mar 2011 11:28:33 +0100 Subject: [Vimprobable-users] Patch: Boundary check for internal settings Message-ID: <20110326112833.23fe65a4@workstation> Hello, find a simple patch to prevent the user intentionally or unintentionally overflowing the internal string variables via :set. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: boundary_check.patch Type: text/x-patch Size: 2295 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 Mar 26 10:29:43 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 26 Mar 2011 11:29:43 +0100 Subject: [Vimprobable-users] [PATCH 3/5] Mention search engines in the man page In-Reply-To: <20110326102501.GC7317@deepsilver> References: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> <1301097015-2831-4-git-send-email-hpdeifel@gmx.de> <20110326003559.GC5651@debian.ttn6tadam> <20110326102501.GC7317@deepsilver> Message-ID: <20110326112943.49e2e4e6@workstation> Hans-Peter Deifel wrote: > I don't think we should strive for conceptual pureness here :) > Sometimes Worse Is Better(TM). Couldn't agree more! Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From hpdeifel at gmx.de Sat Mar 26 10:33:14 2011 From: hpdeifel at gmx.de (Hans-Peter Deifel) Date: Sat, 26 Mar 2011 11:33:14 +0100 Subject: [Vimprobable-users] [PATCH 0/5] Configurable search engines In-Reply-To: <20110326103817.3709b5dc@workstation> References: <1301097015-2831-1-git-send-email-hpdeifel@gmx.de> <20110326103817.3709b5dc@workstation> Message-ID: <20110326103313.GH7317@deepsilver> On 10:38 Sat 26 Mar , Hannes Sch?ller wrote: > Hi! > > Hans-Peter Deifel wrote: > > This patch series introduces a new configuration file for search > > engines, that can contain lines such as: > > > > ddg https://duckduckgo.com/?q=%s > > > > to add 'ddg' to the search engines defined in config.h. > > > > Also, the new setting 'defaultsearch' controls which search engine to > > use. > > I think this would be extremely useful. From the architectural point of > view, I haev only one comment (also noted in one code comment): > > Currently, you're defining a new list of "dynamic" searchengines and > then hierarchically check first that and in the case of no match, check > the default list. This works, but it's not very elegant. > > Please have a look at the keybinding handling. There, we define a > default list in keymap.h and when a new keybinding is defined, it is > either added to that list or the existing binding for that combination > of keys is overwritten. That way, only one lookup is necessary as all > instances are stored in a single list. I think the same principle > should be applied to the searchengine handling. Yes, that's probably better. I will re-roll this series shortly (probably tomorrow, after all the comments have been discussed) Regards, HP -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 230 bytes Desc: not available URL: From hannes at yllr.net Sat Mar 26 10:44:30 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 26 Mar 2011 11:44:30 +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: <20110326114430.3806fb28@workstation> So, any news on this? -------------- 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 Sat Mar 26 11:51:31 2011 From: thomas at xteddy.org (Thomas Adam) Date: Sat, 26 Mar 2011 11:51:31 +0000 Subject: [Vimprobable-users] Patch: Boundary check for internal settings In-Reply-To: <20110326112833.23fe65a4@workstation> References: <20110326112833.23fe65a4@workstation> Message-ID: <20110326115116.GA2089@debian.ttn6tadam> On Sat, Mar 26, 2011 at 11:28:33AM +0100, Hannes Sch?ller wrote: > Hello, > > find a simple patch to prevent the user intentionally or > unintentionally overflowing the internal string variables via :set. Yes, this is fine... > + strncpy(browsersettings[i].var, my_pair.value, MAX_SETTING_SIZE); > + if (strlen(my_pair.value) > MAX_SETTING_SIZE - 1) { > + /* in this case, \0 will not have been copied */ > + browsersettings[i].var[MAX_SETTING_SIZE - 1] = '\0'; > + /* in case this string is also used for a webkit setting, make sure it's consistent */ ... but do we really want to just lop off anything > MAX_SETTING_SIZE and still blindly use it? In the case of setting something like the homepage to something > MAX_SETTING_SIZE -- you do get all sorts of interesting side-effects. :) -- Thomas Adam -- "Deep in my heart I wish I was wrong. But deep in my heart I know I am not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.) From thomas at xteddy.org Sat Mar 26 13:49:07 2011 From: thomas at xteddy.org (Thomas Adam) Date: Sat, 26 Mar 2011 13:49:07 +0000 Subject: [Vimprobable-users] Patch: Boundary check for internal settings In-Reply-To: <20110326125920.2d843cfd@workstation> References: <20110326112833.23fe65a4@workstation> <20110326115116.GA2089@debian.ttn6tadam> <20110326125920.2d843cfd@workstation> Message-ID: Hi -- 2011/3/26 Hannes Sch?ller : > Thomas Adam wrote: >> On Sat, Mar 26, 2011 at 11:28:33AM +0100, Hannes Sch?ller wrote: >> > + ? ? ? ? ? ? ? ? ? ?strncpy(browsersettings[i].var, my_pair.value, >> > MAX_SETTING_SIZE); >> > + ? ? ? ? ? ? ? ? ? ?if (strlen(my_pair.value) > MAX_SETTING_SIZE - >> > 1) { >> > + ? ? ? ? ? ? ? ? ? ? ? ?/* in this case, \0 will not have been >> > copied */ >> > + ? ? ? ? ? ? ? ? ? ? ? ?browsersettings[i].var[MAX_SETTING_SIZE - >> > 1] = '\0'; >> > + ? ? ? ? ? ? ? ? ? ? ? ?/* in case this string is also used for a >> > webkit setting, make sure it's consistent */ >> >> ... but do we really want to just lop off anything > MAX_SETTING_SIZE >> and still blindly use it? ?In the case of setting something like the >> homepage to something > MAX_SETTING_SIZE -- you do get all sorts of >> interesting side-effects. ?:) > > The point is *not* to be *able* to set homepage to anything longer. > How would you manage to do that with this code? I didn't explain this very well -- I know the code prevents that. What I meant was, can you guarantee 1024 to be acceptible, and what should really happen when people try and use something > MAX_SETTING_SIZE? I know 1024 is what we currently use, and probably covers expansion for things like webkit options (I doubt anyone's expected to have an option of 1024 characters!) -- but I am still not sure about the behaviour of cutting a given option off at 1024 and then silently trying to use it. Maybe it won't be an issue. -- Thomas Adam From hannes at yllr.net Sat Mar 26 14:07:23 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 26 Mar 2011 15:07:23 +0100 Subject: [Vimprobable-users] Patch: Boundary check for internal settings In-Reply-To: References: <20110326112833.23fe65a4@workstation> <20110326115116.GA2089@debian.ttn6tadam> <20110326125920.2d843cfd@workstation> Message-ID: <20110326150723.04edeca6@workstation> Thomas Adam wrote: > 2011/3/26 Hannes Sch?ller : > > Thomas Adam wrote: > >> On Sat, Mar 26, 2011 at 11:28:33AM +0100, Hannes Sch?ller wrote: > >> > + ? ? ? ? ? ? ? ? ? ?strncpy(browsersettings[i].var, > >> > my_pair.value, MAX_SETTING_SIZE); > >> > + ? ? ? ? ? ? ? ? ? ?if (strlen(my_pair.value) > > >> > MAX_SETTING_SIZE - 1) { > >> > + ? ? ? ? ? ? ? ? ? ? ? ?/* in this case, \0 will not have been > >> > copied */ > >> > + ? ? ? ? ? ? ? ? ? ? ? ?browsersettings[i].var[MAX_SETTING_SIZE > >> > - 1] = '\0'; > >> > + ? ? ? ? ? ? ? ? ? ? ? ?/* in case this string is also used for > >> > a webkit setting, make sure it's consistent */ > >> > >> ... but do we really want to just lop off anything > > >> MAX_SETTING_SIZE and still blindly use it? ?In the case of setting > >> something like the homepage to something > MAX_SETTING_SIZE -- you > >> do get all sorts of interesting side-effects. ?:) > > > > The point is *not* to be *able* to set homepage to anything longer. > > How would you manage to do that with this code? > > I didn't explain this very well -- I know the code prevents that. > What I meant was, can you guarantee 1024 to be acceptible, and what > should really happen when people try and use something > > MAX_SETTING_SIZE? I know 1024 is what we currently use, and probably > covers expansion for things like webkit options (I doubt anyone's > expected to have an option of 1024 characters!) -- but I am still not > sure about the behaviour of cutting a given option off at 1024 and > then silently trying to use it. Ah, I see what you mean. This cutoff is important because of the useragent string: Only cutting it off for the internal variable will still allow longer strings to be passed to Webkit, resulting in an inconsistent state. Currently, the useragent string is one of two occurences of an internal variable and a Webkit setting overlapping. For that, there will be no problem with a string being arbitrarily cut off. The other one is acceptlanguage. I will run some tests how Webkit reacts if something invalid is set there. If everything else fails, I believe simply returning FALSE if the input string is too long might be the only option. 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 Sat Mar 26 14:16:00 2011 From: thomas at xteddy.org (Thomas Adam) Date: Sat, 26 Mar 2011 14:16:00 +0000 Subject: [Vimprobable-users] Patch: Boundary check for internal settings In-Reply-To: <20110326150723.04edeca6@workstation> References: <20110326112833.23fe65a4@workstation> <20110326115116.GA2089@debian.ttn6tadam> <20110326125920.2d843cfd@workstation> <20110326150723.04edeca6@workstation> Message-ID: 2011/3/26 Hannes Sch?ller : > Ah, I see what you mean. This cutoff is important because of the > useragent string: Only cutting it off for the internal variable will Yes -- this is partly why b08ba6e0195168aacd62ee45e058b0ab26432bd9 is introduced. I remember setting a much larger useragent value than what it was originally set to, and seeing all sorts of corruption in Vimprobable. I think you'll find the same thing with some settings when you come to test it, in which case, yes, maybe a return value of FALSE is OK. Still bear in mind though that this is still somewhat silent -- as a user, I have no way of knowing that a given value to an option I've just used is going to be ignored, or perhaps truncated. I'd recommend the use of something like give_feedback() here. Oh, and in the case of the homepage, for example, the likely reason why someone might enter in a value > MAX_SETTING_SIZE might be because of some long path, or (in the bizaare, but not unlikely case) GET options. Again -- as things currently stand (even before this patch) -- I'll have an entry used which won't work. I don't mind the idea of having an upper limit for the length of options, what I find annoying though is I won't be told about the fact that I'm either having options skipped/ignored, or truncated if they're too long. As a user, it's going to potentially get annoying. -- Thomas Adam From hannes at yllr.net Sat Mar 26 15:26:31 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 26 Mar 2011 16:26:31 +0100 Subject: [Vimprobable-users] Patch: Boundary check for internal settings In-Reply-To: References: <20110326112833.23fe65a4@workstation> <20110326115116.GA2089@debian.ttn6tadam> <20110326125920.2d843cfd@workstation> <20110326150723.04edeca6@workstation> Message-ID: <20110326162631.0cd6e542@workstation> Thomas Adam wrote: > 2011/3/26 Hannes Sch?ller : > > Ah, I see what you mean. This cutoff is important because of the > > useragent string: Only cutting it off for the internal variable will > > Yes -- this is partly why b08ba6e0195168aacd62ee45e058b0ab26432bd9 is > introduced. I remember setting a much larger useragent value than > what it was originally set to, and seeing all sorts of corruption in > Vimprobable. That, however, was not due to an overflow in Webkit, but in the internal variable -- which is now prevented. Right now, we've got useragent and acceptlanguage. None of these causes any problems if truncated. But of course, we cannot know what the future might bring. From that point of view, simply rejecting any input which is too long might be sensible. 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 Sun Mar 27 14:10:14 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sun, 27 Mar 2011 16:10:14 +0200 Subject: [Vimprobable-users] Patch: Boundary check for internal settings In-Reply-To: <20110326112833.23fe65a4@workstation> References: <20110326112833.23fe65a4@workstation> Message-ID: <20110327161014.33410f3e@workstation> Here is a new version of the patch. As per the discussion with Thomas, I added user feedback in case a string is truncated. I did not go for outright rejection of the new setting. Rationale: The users can always set invalid crap through the :set function. This possibility exists regardless of the string length question. Even very short string can contain useless junk. So the situation will never get worse than it already is by truncating strings. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: boundary_check.patch Type: text/x-patch Size: 3834 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 Mon Mar 28 20:44:47 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Mon, 28 Mar 2011 22:44:47 +0200 Subject: [Vimprobable-users] Vimprobable presentation at Linuxtag Message-ID: <20110328224447.773efd3f@workstation> Hello everyone, I've been invited to present the Vimprobable project, talk about the motivations behind it and design and interface principles at this year's Linuxtag. Linuxtag ist a large annual open source conference in Berlin. The presentation will take place on Saturday, May 14th at 4 p.m. and it will take approximately half an hour. More information: http://www.linuxtag.org/2011/en/program/free-conference/popup/details.html?talkid=489 The complete list of presentation of the day: http://www.linuxtag.org/2011/en/program/free-conference/popup/saturday-may-14.html If any of you is attending the conference anyway or now feels motivated to come, drop me a line - maybe we can exchange a few words. I will be attending from Thursday to Saturday, so there'll certainly be more than enough opportunity to meet if anyone feels like it. Hannes P.S. Before anyone asks: Yes, I pointed out the irony of presenting an X-based application in a series of talks about shell tools to the organisers, too. If you're curious how this fits, you should consider attending the presentation ;) -------------- 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 Mon Mar 28 20:49:09 2011 From: thomas at xteddy.org (Thomas Adam) Date: Mon, 28 Mar 2011 21:49:09 +0100 Subject: [Vimprobable-users] Vimprobable presentation at Linuxtag In-Reply-To: <20110328224447.773efd3f@workstation> References: <20110328224447.773efd3f@workstation> Message-ID: Hi -- 2011/3/28 Hannes Sch?ller : > Hello everyone, > > I've been invited to present the Vimprobable project, talk about the > motivations behind it and design and interface principles at this year's > Linuxtag. Linuxtag ist a large annual open source conference in Berlin. Cool! I won't be there, alas, but anything you can report back, or might have filmed, be sure to let us all know! Good luck, Hannes. :) -- Thomas Adam From hannes at yllr.net Mon Mar 28 20:55:12 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Mon, 28 Mar 2011 22:55:12 +0200 Subject: [Vimprobable-users] Vimprobable presentation at Linuxtag In-Reply-To: References: <20110328224447.773efd3f@workstation> Message-ID: <20110328225512.65ff2c22@workstation> Thomas Adam wrote: > or might have filmed Good point, I'll ask whether talks are usually recorded there! Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From matto at matto.nl Tue Mar 29 19:17:54 2011 From: matto at matto.nl (Matto Fransen) Date: Tue, 29 Mar 2011 21:17:54 +0200 Subject: [Vimprobable-users] Vimprobable presentation at Linuxtag In-Reply-To: <20110328224447.773efd3f@workstation> References: <20110328224447.773efd3f@workstation> Message-ID: <20110329191751.GA1846@aspire.tradesystem.nl> Hi, On Mon, Mar 28, 2011 at 10:44:47PM +0200, Hannes Sch?ller wrote: > I've been invited to present the Vimprobable project, talk about the > motivations behind it and design and interface principles at this year's > Linuxtag. Linuxtag ist a large annual open source conference in Berlin. That is really great! > The presentation will take place on Saturday, May 14th at 4 p.m. and > it will take approximately half an hour. More information: > http://www.linuxtag.org/2011/en/program/free-conference/popup/details.html?talkid=489 > > The complete list of presentation of the day: > http://www.linuxtag.org/2011/en/program/free-conference/popup/saturday-may-14.html Well, cgroups might also be an interesting talk :) (/me is toying a lot the last few months with LXC Linux containers) > If any of you is attending the conference anyway or now feels motivated > to come, drop me a line - maybe we can exchange a few words. I will be > attending from Thursday to Saturday, so there'll certainly be more than > enough opportunity to meet if anyone feels like it. Unfortunately (well...) I will be on holiday in Greece. > Hannes > P.S. Before anyone asks: Yes, I pointed out the irony of presenting an > X-based application in a series of talks about shell tools to the > organisers, too. If you're curious how this fits, you should consider > attending the presentation ;) Suckless.org is the second talk after you. So that comes close :) Anyway, I think it is great that you have been invited to present Vimprobable to the audience. Cheers, Matto -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: