From matto at matto.nl Mon Nov 1 08:27:34 2010 From: matto at matto.nl (Matto Fransen) Date: Mon, 1 Nov 2010 09:27:34 +0100 Subject: [Vimprobable-users] opening lots of URLS at once? In-Reply-To: References: Message-ID: <20101101082732.GA2000@aspire.tradesystem.nl> Hi Michael, On Sun, Oct 31, 2010 at 10:08:12PM +0000, Michael Treibton wrote: > is it possible to open up a lot of urls at once with vimprobable? what > about via bookmarks? > This is possible with the use of tags. When creating a bookmark, you can give it one of more tags. Like :bma macarena When you want to open all bookmarks with the tag macarena, you do :qt macarena Cheers, Matto -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From hannes at yllr.net Mon Nov 1 08:26:41 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Mon, 1 Nov 2010 09:26:41 +0100 Subject: [Vimprobable-users] yahoo/gmail single sign-in In-Reply-To: References: <20101031214714.7d71a590@workstation> Message-ID: <20101101082638.GA2500@laptop2.lan.localhost> On Sun, Oct 31, 2010 at 09:11:20PM +0000, Michael Treibton wrote: > 2010/10/31 Hannes Sch?ller : > > Michael Treibton wrote: > >> i have one question - when i sign-in to gmail or yahoo - and click the > >> "keep me logged in" option, vimprobable2 doesnt honor this - rather, > >> it will always ask me to re-sign in, even when linking to calendars > >> from the same page ive signed in from already > > > > Do these open in a new window? If so, please wait for the next release > > which will address this thanks to Thomas' great cookie handling patch > > posted here on the list a week ago. > > oh - thats really good! thanks Hannes!! when is the next release? and > yes, they do open in new windows I hope to get it out this week, but it's quite a few bigger patches/changes. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From hannes at yllr.net Mon Nov 1 08:29:46 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Mon, 1 Nov 2010 09:29:46 +0100 Subject: [Vimprobable-users] tabbed interface for vimprobable2? In-Reply-To: References: Message-ID: <20101101082944.GB2500@laptop2.lan.localhost> On Sun, Oct 31, 2010 at 09:14:03PM +0000, Michael Treibton wrote: > i know its in the faq - but why doesnt vimprobable consider using > native tabs? wouldnt this help with sharing data between diffrent > vimprobable windows? i am sure its not much code? The supposedly 'easy' way to do it within Vimprobable would have two major disadvanteges: 1. Just one process, i.e. one non-responsive tab would block them all. 2. Setting would be globally valid, i.e. you couldn't enable Javascript just for one tab, for example, but only for all of them at once. Both would be extremely inconvenient. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From hannes at yllr.net Mon Nov 1 20:24:55 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Mon, 1 Nov 2010 21:24:55 +0100 Subject: [Vimprobable-users] [PATCH] Fix ftp:// and ftp. support. In-Reply-To: <20101020201522.GA16739@shuttle.home> References: <20101020201522.GA16739@shuttle.home> Message-ID: <20101101202454.GA1950@laptop2.lan.localhost> Hi! On Wed, Oct 20, 2010 at 09:15:26PM +0100, Thomas Adam wrote: > libwebkit has no direct support for opening FTP sites, but will allow so > over HTTP. That's fine, but Vimprobable has to support this by doing the > following: > > (String prependage.) > ftp.example.com => http://ftp.example.com > > (String prependage, having removed ftp:// prefix, hence): > ftp://ftp.example.com => http://ftp.example.com This does not seem to work for me. Clicking on any ftp:// links, the browser claims something is not mounted. Any ideas? Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From hannes at yllr.net Mon Nov 1 20:36:48 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Mon, 1 Nov 2010 21:36:48 +0100 Subject: [Vimprobable-users] [PATCH] Free values in echo() by default. In-Reply-To: <20101022091752.GA8158@abacus.soton.smoothwall.net> References: <20101022091752.GA8158@abacus.soton.smoothwall.net> Message-ID: <20101101203647.GB1950@laptop2.lan.localhost> On Fri, Oct 22, 2010 at 10:18:07AM +0100, Thomas Adam wrote: > There's too many instances where the caller of echo() has > malloc()d a char* but never frees it, resulting in annoying memory-leaks. > > Try and reduce this by always freeing the data received to echo(). Merged -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From hannes at yllr.net Mon Nov 1 20:37:48 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Mon, 1 Nov 2010 21:37:48 +0100 Subject: [Vimprobable-users] [PATCH v2 0/9] Revamp cookie support In-Reply-To: <20101025150342.GA8916@abacus.soton.smoothwall.net> References: <20101025150342.GA8916@abacus.soton.smoothwall.net> Message-ID: <20101101203747.GC1950@laptop2.lan.localhost> Merged -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From robin.kreis at uni-bremen.de Mon Nov 1 21:06:10 2010 From: robin.kreis at uni-bremen.de (Robin Kreis) Date: Mon, 1 Nov 2010 22:06:10 +0100 Subject: [Vimprobable-users] [PATCH] Fix ftp:// and ftp. support. In-Reply-To: <20101020201522.GA16739@shuttle.home> References: <20101020201522.GA16739@shuttle.home> Message-ID: <20101101220610.6164fa79.robin.kreis@uni-bremen.de> On Wed, 20 Oct 2010 21:15:26 +0100 Thomas Adam wrote: > libwebkit has no direct support for opening FTP sites, but will allow so > over HTTP. That's fine, but Vimprobable has to support this by doing the > following: > > (String prependage.) > ftp.example.com => http://ftp.example.com > > (String prependage, having removed ftp:// prefix, hence): > ftp://ftp.example.com => http://ftp.example.com Hi! I don't think translating ftp:// URLs to http:// is a nice thing to do. If the user accesses an ftp:// URL, that's what should happen - the user can enter http:// himself if he wants to access an FTP server over HTTP (remember that this doesn't have to work). I suggest redirecting the request to an FTP client (will xdg-open do it?). I would rather have my ftp:// URLs opened in, say, nautilus instead of having a directory listing generated by my browser or the FTP server - it's just the better way of showing a directory structure. I alternatively suggest not supporting FTP at all and displaying a message which lists the options (using http:// or another program). Have a good time, Robin -- Sargdeckel f?llt - die Witwe kichert, der Bauer war wohl gut versichert. From thomas at xteddy.org Mon Nov 1 21:13:20 2010 From: thomas at xteddy.org (Thomas Adam) Date: Mon, 1 Nov 2010 21:13:20 +0000 Subject: [Vimprobable-users] [PATCH] Fix ftp:// and ftp. support. In-Reply-To: <20101101202454.GA1950@laptop2.lan.localhost> References: <20101020201522.GA16739@shuttle.home> <20101101202454.GA1950@laptop2.lan.localhost> Message-ID: <20101101211317.GA3403@shuttle.home> On Mon, Nov 01, 2010 at 09:24:55PM +0100, Hannes Sch?ller wrote: > Hi! > > On Wed, Oct 20, 2010 at 09:15:26PM +0100, Thomas Adam wrote: > > libwebkit has no direct support for opening FTP sites, but will allow so > > over HTTP. That's fine, but Vimprobable has to support this by doing the > > following: > > > > (String prependage.) > > ftp.example.com => http://ftp.example.com > > > > (String prependage, having removed ftp:// prefix, hence): > > ftp://ftp.example.com => http://ftp.example.com > > This does not seem to work for me. Clicking on any ftp:// links, the > browser claims something is not mounted. Any ideas? Yes -- we kindly "return FALSE" in the callback which handles "navigation-policy-decision-requested" signals -- hence, no translation of any URI object is ever performed once the page has loaded -- and as this callback is called when following links, for instance, then they're taken verbatim, and never go through our open() routine. But there are other issues here -- as various callbacks also blindly call webkit_web_view_load_uri() in some instances, and hence suffer the same potential problem. The more I look at it, the more of a nightmare this is to special case something which is not supported upstream. Pull this patch for now, Hannes. I will think on it some more, as it's flagging up other more pressing issues with how we're (not) handling other events, but ought to. If we fix those, transliterating ftp:// links becomes a nice by-product of 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 Mon Nov 1 21:15:37 2010 From: thomas at xteddy.org (Thomas Adam) Date: Mon, 1 Nov 2010 21:15:37 +0000 Subject: [Vimprobable-users] [PATCH] Fix ftp:// and ftp. support. In-Reply-To: <20101101220610.6164fa79.robin.kreis@uni-bremen.de> References: <20101020201522.GA16739@shuttle.home> <20101101220610.6164fa79.robin.kreis@uni-bremen.de> Message-ID: <20101101211536.GB3403@shuttle.home> On Mon, Nov 01, 2010 at 10:06:10PM +0100, Robin Kreis wrote: > On Wed, 20 Oct 2010 21:15:26 +0100 > Thomas Adam wrote: > > > libwebkit has no direct support for opening FTP sites, but will allow so > > over HTTP. That's fine, but Vimprobable has to support this by doing the > > following: > > > > (String prependage.) > > ftp.example.com => http://ftp.example.com > > > > (String prependage, having removed ftp:// prefix, hence): > > ftp://ftp.example.com => http://ftp.example.com > > Hi! > > I don't think translating ftp:// URLs to http:// is a nice thing to > do. If the user accesses an ftp:// URL, that's what should happen - Tough -- that's what webkit recommend, that's the only thing we can do. :) > the user can enter http:// himself if he wants to access an FTP server > over HTTP (remember that this doesn't have to work). > > I suggest redirecting the request to an FTP client (will xdg-open do > it?). I would rather have my ftp:// URLs opened in, say, nautilus No xdg-open will not do it. > instead of having a directory listing generated by my browser or the FTP > server - it's just the better way of showing a directory structure. > > I alternatively suggest not supporting FTP at all and displaying a > message which lists the options (using http:// or another program). I disagree -- this is solvable at the client-end fairly trivially (see previous) email, in lieu of upstream not supporting this. It's a known "issue", anyway. -- 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 Tue Nov 2 13:33:55 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Tue, 2 Nov 2010 14:33:55 +0100 Subject: [Vimprobable-users] Patch to make tabcompletion on bookmarks case-insensitive In-Reply-To: <20101029131850.GA3066@aspire.tradesystem.nl> References: <20101029131850.GA3066@aspire.tradesystem.nl> Message-ID: <20101102133352.GA1972@laptop2.lan.localhost> Hi! On Fri, Oct 29, 2010 at 03:18:53PM +0200, Matto Fransen wrote: > Below a small patch to make tabcompletion on bookmarks case-insensitive :) I have extended this to refer to both bookmarks and history completion and made it configurable (via :set in v2). Merged into the next release. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From robin.kreis at uni-bremen.de Tue Nov 2 16:45:36 2010 From: robin.kreis at uni-bremen.de (Robin Kreis) Date: Tue, 2 Nov 2010 17:45:36 +0100 Subject: [Vimprobable-users] [PATCH] Fix ftp:// and ftp. support. In-Reply-To: <20101101211536.GB3403@shuttle.home> References: <20101020201522.GA16739@shuttle.home> <20101101220610.6164fa79.robin.kreis@uni-bremen.de> <20101101211536.GB3403@shuttle.home> Message-ID: <20101102174536.87de621a.robin.kreis@uni-bremen.de> We continued this discussion on the vimprobable IRC channel. My log is attached. -- H?lsenfrucht zum Abendbrot, morgens sind die Fliegen tot. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: irclog URL: From matto at matto.nl Tue Nov 2 19:48:40 2010 From: matto at matto.nl (Matto Fransen) Date: Tue, 2 Nov 2010 20:48:40 +0100 Subject: [Vimprobable-users] Patch to make tabcompletion on bookmarks case-insensitive In-Reply-To: <20101102133352.GA1972@laptop2.lan.localhost> References: <20101029131850.GA3066@aspire.tradesystem.nl> <20101102133352.GA1972@laptop2.lan.localhost> Message-ID: <20101102194836.GA1810@aspire.tradesystem.nl> Hi, On Tue, Nov 02, 2010 at 02:33:55PM +0100, Hannes Sch?ller wrote: > > Below a small patch to make tabcompletion on bookmarks case-insensitive :) > > I have extended this to refer to both bookmarks and history completion > and made it configurable (via :set in v2). Merged into the next release. Nice! Cheers, Matto -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From hannes at yllr.net Fri Nov 5 18:53:24 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Fri, 5 Nov 2010 19:53:24 +0100 Subject: [Vimprobable-users] improved patch for tag-completion In-Reply-To: <20101027191506.GA2001@aspire.tradesystem.nl> References: <20101027191506.GA2001@aspire.tradesystem.nl> Message-ID: <20101105195324.52d1c9e7@workstation> As per your suggestion, I've built upon your marvelous list handling in order to reduce some of the clutter of the complete() function. It's not down to below 200 lines of code, by a few indentation levels and has got a lot less redundancies. I still have to port this to the Vimprobable1 branch before the next set of releases. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From thomas at xteddy.org Fri Nov 5 19:37:12 2010 From: thomas at xteddy.org (Thomas Adam) Date: Fri, 5 Nov 2010 19:37:12 +0000 Subject: [Vimprobable-users] improved patch for tag-completion In-Reply-To: <20101105195324.52d1c9e7@workstation> References: <20101027191506.GA2001@aspire.tradesystem.nl> <20101105195324.52d1c9e7@workstation> Message-ID: <20101105193710.GA3568@shuttle.home> Hi -- On Fri, Nov 05, 2010 at 07:53:24PM +0100, Hannes Sch?ller wrote: > As per your suggestion, I've built upon your marvelous list handling in > order to reduce some of the clutter of the complete() function. It's > not down to below 200 lines of code, by a few indentation levels and > has got a lot less redundancies. Is this available for (re)viewing? -- 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 Fri Nov 5 19:44:25 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Fri, 5 Nov 2010 20:44:25 +0100 Subject: [Vimprobable-users] improved patch for tag-completion In-Reply-To: <20101105193710.GA3568@shuttle.home> References: <20101027191506.GA2001@aspire.tradesystem.nl> <20101105195324.52d1c9e7@workstation> <20101105193710.GA3568@shuttle.home> Message-ID: <20101105204425.5388b881@workstation> > On Fri, Nov 05, 2010 at 07:53:24PM +0100, Hannes Sch?ller wrote: > > As per your suggestion, I've built upon your marvelous list > > handling in order to reduce some of the clutter of the complete() > > function. It's not down to below 200 lines of code, by a few > > indentation levels and has got a lot less redundancies. > > Is this available for (re)viewing? Sure: http://www.vimprobable.org/complete_cleanup.patch This is on top of Matto's patch. 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 Fri Nov 5 20:06:41 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Fri, 5 Nov 2010 21:06:41 +0100 Subject: [Vimprobable-users] improved patch for tag-completion In-Reply-To: <20101105193710.GA3568@shuttle.home> References: <20101027191506.GA2001@aspire.tradesystem.nl> <20101105195324.52d1c9e7@workstation> <20101105193710.GA3568@shuttle.home> Message-ID: <20101105210641.7e4f26e4@workstation> Thomas Adam wrote: > On Fri, Nov 05, 2010 at 07:53:24PM +0100, Hannes Sch?ller wrote: > > As per your suggestion, I've built upon your marvelous list > > handling in order to reduce some of the clutter of the complete() > > function. It's not down to below 200 lines of code, by a few > > indentation levels and has got a lot less redundancies. > > Is this available for (re)viewing? Two more (cumulative) which occured to me when porting: http://www.vimprobable.org/listsize.patch (this problem didn't come up in Vimprobable2 by pure chance, still a bad mistake - caused Vimprobable1 to crash) http://www.vimprobable.org/free_suggurls.patch (memory leak) 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 Fri Nov 5 20:25:23 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Fri, 5 Nov 2010 21:25:23 +0100 Subject: [Vimprobable-users] improved patch for tag-completion In-Reply-To: <20101105193710.GA3568@shuttle.home> References: <20101027191506.GA2001@aspire.tradesystem.nl> <20101105195324.52d1c9e7@workstation> <20101105193710.GA3568@shuttle.home> Message-ID: <20101105212523.1f85b8b3@workstation> Thomas Adam wrote: > On Fri, Nov 05, 2010 at 07:53:24PM +0100, Hannes Sch?ller wrote: > > As per your suggestion, I've built upon your marvelous list > > handling in order to reduce some of the clutter of the complete() > > function. It's not down to below 200 lines of code, by a few > > indentation levels and has got a lot less redundancies. > > Is this available for (re)viewing? Don't bother for now. I found a major functional issue (hitting tab to go to the next suggestion doesn't work as expected). Back to the drawing board. 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 Fri Nov 5 20:47:12 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Fri, 5 Nov 2010 21:47:12 +0100 Subject: [Vimprobable-users] improved patch for tag-completion In-Reply-To: <20101105193710.GA3568@shuttle.home> References: <20101027191506.GA2001@aspire.tradesystem.nl> <20101105195324.52d1c9e7@workstation> <20101105193710.GA3568@shuttle.home> Message-ID: <20101105214712.1886f68b@workstation> Thomas Adam wrote: > > As per your suggestion, I've built upon your marvelous list > > handling in order to reduce some of the clutter of the complete() > > function. It's not down to below 200 lines of code, by a few > > indentation levels and has got a lot less redundancies. > > Is this available for (re)viewing? Alright... http://www.vimprobable.org/complete_cleanup2.patch Seems to be working again as expected. Waiting for comments, but don't expect too much. I touched only half of the complete() function so far. 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 Fri Nov 5 23:21:26 2010 From: mtreibton at googlemail.com (Michael Treibton) Date: Fri, 5 Nov 2010 23:21:26 +0000 Subject: [Vimprobable-users] patches guidelines? Message-ID: hi everyone are there any rules or notes about how i should use git with vimprobable? i am thinking about applying or creating patches - as i am new to git and dont know what rules vimprobable has if any! Thanks all! Michael From hannes at yllr.net Sat Nov 6 08:45:44 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 6 Nov 2010 09:45:44 +0100 Subject: [Vimprobable-users] patches guidelines? In-Reply-To: References: Message-ID: <20101106094544.28069934@workstation> Hi! Michael Treibton wrote: > are there any rules or notes about how i should use git with > vimprobable? i am thinking about applying or creating patches - as i > am new to git and dont know what rules vimprobable has if any! Thomas posted a guideline for that on this list a few days ago. I think it's a good basis. It'll be included in the next release. 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 Nov 6 10:57:44 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sat, 6 Nov 2010 10:57:44 +0000 Subject: [Vimprobable-users] improved patch for tag-completion In-Reply-To: <20101105214712.1886f68b@workstation> References: <20101027191506.GA2001@aspire.tradesystem.nl> <20101105195324.52d1c9e7@workstation> <20101105193710.GA3568@shuttle.home> <20101105214712.1886f68b@workstation> Message-ID: <20101106105741.GA3473@shuttle.home> On Fri, Nov 05, 2010 at 09:47:12PM +0100, Hannes Sch?ller wrote: > Thomas Adam wrote: > > > As per your suggestion, I've built upon your marvelous list > > > handling in order to reduce some of the clutter of the complete() > > > function. It's not down to below 200 lines of code, by a few > > > indentation levels and has got a lot less redundancies. > > > > Is this available for (re)viewing? > > Alright... http://www.vimprobable.org/complete_cleanup2.patch > > Seems to be working again as expected. Waiting for comments, but don't > expect too much. I touched only half of the complete() function so far. This looks OK -- I mean, it's still a mess, but then I don't know how far you were thinking of cleaning this up. There's the usual things to note though: * Not checking for success on realloc() * Still the use of (in utilities.c:complete_tags()): free ((void *) filename); Rather than: g_free(filename) * Still a lot of whitespace corruption. * There's far too much tangling of data and gtk_event_box() filling. I am not saying we should do this now -- but rather than having massive chunks of nested if/else blocks, we split that off to separate functions: complete_bookmarks() complete_urls() complete_bookmark_tags() ... and all they do is shunt data into a *passed in* list, and then at the very end put it for inclusion to a gtk_event_box() widget. You might find of course that, given the similarity of bookmarks and urls that they're combined in functionality -- as they both read from a file anyway. -- 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 Sun Nov 7 19:28:01 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sun, 7 Nov 2010 20:28:01 +0100 Subject: [Vimprobable-users] Vimprobable 0.9.20.0 & Vimprobable2 0.9.6.0 released! Message-ID: <20101107202801.5bed6a97@workstation> Hello everyone, both branches received some major new features today: - Improved cookie handling: Thomas Adam (without 's', sorry for getting it wrong in the commit) overhauled this function to allow for cookie sharing (and consequently, cookie-based session sharing) between browser instances. In practice, this means that for example when you're logged in to some service and follow a link in a new window there, you won't have to authenticate again. The limitation is that this functionality won't mix with setting cookies to 'session only'. To take advantage of the advanced sharing functionality, make sure you have COOKIES_STORAGE_READONLY to TRUE in config.h (this is the default setting). - Tag completion: So far, using tab completion for the :qt function would produce a list of URLs tagged with what you were looking for. The point of the :qt command was always to open more than one URL at once, though. That is why Matto Fransen switched the behaviour to offer suggestions for completing the *actual tag*. - Option for case insensitive tab completion: Matto again - set complete_case_sensitive in config.h to FALSE to match 'S' with 's' and so on. In Vimprobable2, you can also do :set completioncase=(true|false) in vimprobablerc or on runtime. In addition, there has been quite a bit of work on the internals, reducing code redundancy, extending some of the above patches to become more generic, fixing some bugs (memory leaks), documentation updates etc. That is to say, while Thomas and Matto did most of the heavy lifting, I haven't been completely useless, either :) Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From thomas at xteddy.org Sun Nov 7 23:15:52 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sun, 7 Nov 2010 23:15:52 +0000 Subject: [Vimprobable-users] [PATCH REROLL 1/1] Saner config file checking. Message-ID: <20101107231547.GA30365@shuttle.home> Don't moan if RCFILE cannot be opened -- instead, use give_feedback() if an explicit config file was passed on the command-line, but couldn't be opened. For everything else, use an explicit error, because we assume the file could be opened, but not parsed for some reason. --- This appears to have fallen through the cracks... Have updated it to sit atop of 0.9.20. I broke this by mistake when I introduced "-c" on the command line. main.c | 20 +++++++++++++++++--- 1 files changed, 17 insertions(+), 3 deletions(-) diff --git a/main.c b/main.c index 99ce2b0..5ec92c8 100644 --- a/main.c +++ b/main.c @@ -2308,6 +2308,7 @@ main(int argc, char *argv[]) { static Arg a; static char url[256] = ""; static gboolean ver = false; + static gboolean configfile_exists = false; static const char *cfile = NULL; static GOptionEntry opts[] = { { "version", 'v', 0, G_OPTION_ARG_NONE, &ver, "print version", NULL }, @@ -2348,12 +2349,25 @@ main(int argc, char *argv[]) { setup_cookies(); #endif + /* Check if the specified file exists. */ + /* And only warn the user, if they explicitly asked for a config on the + * command line. + */ + if (!(access(configfile, F_OK) == 0) && cfile) { + char *feedback_str; + + feedback_str = g_strdup_printf("Config file '%s' doesn't exist", cfile); + give_feedback(feedback_str); + } else if ((access(configfile, F_OK) == 0)) + configfile_exists = true; + /* read config file */ - if (!read_rcfile(configfile)) { - free(configfile); + /* But only report errors if we failed, and the file existed. */ + if (!read_rcfile(configfile) && configfile_exists) { a.i = Error; - a.s = g_strdup_printf("Error in config file"); + a.s = g_strdup_printf("Error in config file '%s'", configfile); echo(&a); + g_free(configfile); } /* command line argument: URL */ -- 1.7.1 From hannes at yllr.net Mon Nov 8 20:44:17 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Mon, 8 Nov 2010 21:44:17 +0100 Subject: [Vimprobable-users] [PATCH REROLL 1/1] Saner config file checking. In-Reply-To: <20101107231547.GA30365@shuttle.home> References: <20101107231547.GA30365@shuttle.home> Message-ID: <20101108214417.1835bcdb@workstation> Merged -------------- 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 Nov 8 20:50:25 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Mon, 8 Nov 2010 21:50:25 +0100 Subject: [Vimprobable-users] [PATCH v2 1/1] Introduce the SubmittingPatches document In-Reply-To: <20101028192808.GA11658@shuttle.home> References: <20101028192808.GA11658@shuttle.home> Message-ID: <20101108215025.2d792eb0@workstation> Added, thanks! -------------- 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 Nov 8 21:03:49 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Mon, 8 Nov 2010 22:03:49 +0100 Subject: [Vimprobable-users] Vimprobable 0.9.20.1 & Vimprobable2 0.9.6.1 released! Message-ID: <20101108220349.12006bfa@workstation> The "things I forgot yesterday" release includes Thomas Adam's guideline about submitting patches as well as a few small bugfixes: - More graceful handling of missing config files being submitted as a command line option. - Correct handling of the keypad "0" in hinting mode. - Accepting the "Enter" key as an alternative to "Return" to follow a hint. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From skottish97215 at gmail.com Wed Nov 10 01:39:57 2010 From: skottish97215 at gmail.com (Skottish) Date: Tue, 9 Nov 2010 17:39:57 -0800 Subject: [Vimprobable-users] Bookmarks aren't working at all anymore with :open Message-ID: I upgraded vimprobable2 yesterday to 0.9.6.1 and now my bookmarks don't work at all anymore with :open. For instance, if I hit: o --> x2 --> tab I would get the list of all of my links to x264 regardless if there were tags or not. Now I simply get "No Completions". Interestingly, if I type one single letter (doesn't matter which) and hit tab, I get the exact same behavior as if I just hit tab. I've tried with my own config and the default to no avail. Am I not understanding the new system? -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas at xteddy.org Wed Nov 10 11:38:02 2010 From: thomas at xteddy.org (Thomas Adam) Date: Wed, 10 Nov 2010 11:38:02 +0000 Subject: [Vimprobable-users] Bookmarks aren't working at all anymore with :open In-Reply-To: References: Message-ID: <20101110113800.GA2877@abacus.soton.smoothwall.net> On Tue, Nov 09, 2010 at 05:39:57PM -0800, Skottish wrote: > I upgraded vimprobable2 yesterday to 0.9.6.1 and now my bookmarks don't work > at all anymore with :open. For instance, if I hit: > > o --> x2 --> tab > > I would get the list of all of my links to x264 regardless if there were > tags or not. Now I simply get "No Completions". Interestingly, if I type one > single letter (doesn't matter which) and hit tab, I get the exact same > behavior as if I just hit tab. I've tried with my own config and the default > to no avail. Am I not understanding the new system? I'm unable to replicate this at all. Are you sure there's no other piece of information that's needed to reproduce this problem? -- Thomas Adam From skottish97215 at gmail.com Thu Nov 11 03:10:30 2010 From: skottish97215 at gmail.com (Skottish) Date: Wed, 10 Nov 2010 19:10:30 -0800 Subject: [Vimprobable-users] Bookmarks aren't working at all anymore with :open In-Reply-To: <20101110113800.GA2877@abacus.soton.smoothwall.net> References: <20101110113800.GA2877@abacus.soton.smoothwall.net> Message-ID: Not that I'm aware of. What I posted doesn't work and I can't log into my bank anymore. Just to test, I once again completely built from scratch with the default config.h and keymap.h. I get the exact same results. For now I'm reverted back to 0.9.4.0. Like the last time I could reproduce bugs that others can't, I'll throw this out to the Arch community and see if they can. On Wed, Nov 10, 2010 at 3:38 AM, Thomas Adam wrote: > On Tue, Nov 09, 2010 at 05:39:57PM -0800, Skottish wrote: > > I upgraded vimprobable2 yesterday to 0.9.6.1 and now my bookmarks don't > work > > at all anymore with :open. For instance, if I hit: > > > > o --> x2 --> tab > > > > I would get the list of all of my links to x264 regardless if there were > > tags or not. Now I simply get "No Completions". Interestingly, if I type > one > > single letter (doesn't matter which) and hit tab, I get the exact same > > behavior as if I just hit tab. I've tried with my own config and the > default > > to no avail. Am I not understanding the new system? > > I'm unable to replicate this at all. Are you sure there's no other piece > of > information that's needed to reproduce this problem? > > -- Thomas Adam > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas at xteddy.org Thu Nov 11 09:25:34 2010 From: thomas at xteddy.org (Thomas Adam) Date: Thu, 11 Nov 2010 09:25:34 +0000 Subject: [Vimprobable-users] Bookmarks aren't working at all anymore with :open In-Reply-To: References: <20101110113800.GA2877@abacus.soton.smoothwall.net> Message-ID: <20101111092532.GB2888@abacus.soton.smoothwall.net> Hello. On Wed, Nov 10, 2010 at 07:10:30PM -0800, Skottish wrote: > Not that I'm aware of. What I posted doesn't work and I can't log into my > bank anymore. Just to test, I once again completely built from scratch with > the default config.h and keymap.h. I get the exact same results. > > For now I'm reverted back to 0.9.4.0. Like the last time I could reproduce > bugs that others can't, I'll throw this out to the Arch community and see if > they can. Don't bother asking the Arch community. I can only assume that *ONE* of your files, be it your history or bookmarks file is empty? That being the case, then yes, the current completion logic is broken. From main.c:complete(): } else { /* URL completion: bookmarks */ elementlist = complete_list(searchfor, 0, elementlist); m = count_list(elementlist); if (m < MAX_LIST_SIZE) { /* URL completion: history */ elementlist = complete_list(searchfor, 2, elementlist); } Hence, if your history file was empty, elementlist would be overwritten with NULL, invalidating any matches you previously might have found from looking in the bookmarks file. This isn't right. :) Hannes -- one for you to sort out. Should be very easy to do, but I am too busy to do anything on this at the moment. Skottish -- if you don't hear from Hannes or myself by tomorrow, let me know and I'll find some time to fix this. Oh, and as an aside -- try not to top-post. :) -- Thomas Adam From hannes at yllr.net Thu Nov 11 17:30:28 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Thu, 11 Nov 2010 18:30:28 +0100 Subject: [Vimprobable-users] Bookmarks aren't working at all anymore with :open In-Reply-To: <20101111092532.GB2888@abacus.soton.smoothwall.net> References: <20101110113800.GA2877@abacus.soton.smoothwall.net> <20101111092532.GB2888@abacus.soton.smoothwall.net> Message-ID: <20101111183028.2cc07ff0@workstation> Hi! Thomas Adam wrote: > On Wed, Nov 10, 2010 at 07:10:30PM -0800, Skottish wrote: > > Not that I'm aware of. What I posted doesn't work and I can't log > > into my bank anymore. Just to test, I once again completely built > > from scratch with the default config.h and keymap.h. I get the > > exact same results. > > > > For now I'm reverted back to 0.9.4.0. Like the last time I could > > reproduce bugs that others can't, I'll throw this out to the Arch > > community and see if they can. > > Don't bother asking the Arch community. I can only assume that *ONE* > of your files, be it your history or bookmarks file is empty? That > being the case, then yes, the current completion logic is broken. > > From main.c:complete(): > > } else { > /* URL completion: bookmarks */ > elementlist = complete_list(searchfor, 0, > elementlist); m = count_list(elementlist); > if (m < MAX_LIST_SIZE) { > /* URL completion: history */ > elementlist = complete_list(searchfor, 2, > elementlist); } > > Hence, if your history file was empty, elementlist would be > overwritten with NULL, invalidating any matches you previously might > have found from looking in the bookmarks file. Well spotted! I'll fix this and update the repository tonight. 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 Thu Nov 11 18:08:03 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Thu, 11 Nov 2010 19:08:03 +0100 Subject: [Vimprobable-users] Vimprobable 0.9.20.2 & Vimprobable2 0.9.6.2 released! Message-ID: <20101111190803.08f903d3@workstation> This release fixes the issue of no tab completion results from the bookmarks being displayed if history has been turned off or simply couldn't be found. Thanks to Skottish for the report and Thomas for finding the cause! Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From skottish97215 at gmail.com Fri Nov 12 02:00:25 2010 From: skottish97215 at gmail.com (Skottish) Date: Thu, 11 Nov 2010 18:00:25 -0800 Subject: [Vimprobable-users] Bookmarks aren't working at all anymore with :open In-Reply-To: <20101111183028.2cc07ff0@workstation> References: <20101110113800.GA2877@abacus.soton.smoothwall.net> <20101111092532.GB2888@abacus.soton.smoothwall.net> <20101111183028.2cc07ff0@workstation> Message-ID: Yup. I didn't even have a history file because I don't keep any. Thanks a bunch. 2010/11/11 Hannes Sch?ller > Hi! > > Thomas Adam wrote: > > On Wed, Nov 10, 2010 at 07:10:30PM -0800, Skottish wrote: > > > Not that I'm aware of. What I posted doesn't work and I can't log > > > into my bank anymore. Just to test, I once again completely built > > > from scratch with the default config.h and keymap.h. I get the > > > exact same results. > > > > > > For now I'm reverted back to 0.9.4.0. Like the last time I could > > > reproduce bugs that others can't, I'll throw this out to the Arch > > > community and see if they can. > > > > Don't bother asking the Arch community. I can only assume that *ONE* > > of your files, be it your history or bookmarks file is empty? That > > being the case, then yes, the current completion logic is broken. > > > > From main.c:complete(): > > > > } else { > > /* URL completion: bookmarks */ > > elementlist = complete_list(searchfor, 0, > > elementlist); m = count_list(elementlist); > > if (m < MAX_LIST_SIZE) { > > /* URL completion: history */ > > elementlist = complete_list(searchfor, 2, > > elementlist); } > > > > Hence, if your history file was empty, elementlist would be > > overwritten with NULL, invalidating any matches you previously might > > have found from looking in the bookmarks file. > > Well spotted! I'll fix this and update the repository tonight. > > Hannes > > _______________________________________________ > Vimprobable-users mailing list > Vimprobable-users at vimprobable.org > http://vimprobable.org/mailman/listinfo/vimprobable-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skottish97215 at gmail.com Fri Nov 12 04:22:45 2010 From: skottish97215 at gmail.com (Skottish) Date: Thu, 11 Nov 2010 20:22:45 -0800 Subject: [Vimprobable-users] vimprobable2 0.9.6.x can't log into some sites Message-ID: Hi, it's me again. vimprobable2 0.9.x can't log into some sites that worked perfectly with 0.9.4. For instance, I can't log into my bank or ISP anymore. It doesn't matter if I have COOKIES_STORAGE_READONLY set to TRUE (my usual) or not. Logging into other sites like bbs.archlinux.org work as expected. It's difficult for me to show an example for obvious reasons, so if there's something that I can do to help, I'll be glad to. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas at xteddy.org Fri Nov 12 04:28:49 2010 From: thomas at xteddy.org (Thomas Adam) Date: Fri, 12 Nov 2010 04:28:49 +0000 Subject: [Vimprobable-users] vimprobable2 0.9.6.x can't log into some sites In-Reply-To: References: Message-ID: <20101112042847.GA3590@shuttle.home> On Thu, Nov 11, 2010 at 08:22:45PM -0800, Skottish wrote: > Hi, it's me again. > > vimprobable2 0.9.x can't log into some sites that worked perfectly with > 0.9.4. For instance, I can't log into my bank or ISP anymore. It doesn't > matter if I have COOKIES_STORAGE_READONLY set to TRUE (my usual) or not. > Logging into other sites like bbs.archlinux.org work as expected. It's > difficult for me to show an example for obvious reasons, so if there's > something that I can do to help, I'll be glad to. Hmm -- the last time I looked into a problem of yours, it turned out I had to do a massive amount of unnecessary inference. Find a site that is something I can look at which isn't going to rely on SSL or some other site which requires personal information. What you can do, is with 0.9.4, turn of cookie support entirely and see whether you can still use those sites just fine. If you can't, then it's not a cookie problem. If you can reproduce this still with the latest release, then it *might* be cookie-related, but I will highly doubt this, since you're also throwing SSL into this mix. -- 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 jasonwryan at gmail.com Fri Nov 12 22:08:25 2010 From: jasonwryan at gmail.com (Jason Ryan) Date: Sat, 13 Nov 2010 11:08:25 +1300 Subject: [Vimprobable-users] [PATCH] Don't concatenate the last two bookmark tags In-Reply-To: <1287431112-26978-1-git-send-email-hpdeifel@gmx.de> References: <1287431112-26978-1-git-send-email-hpdeifel@gmx.de> Message-ID: <20101112220825.GA12438@Archer> On 18/10/10 at 09:45pm, Hans-Peter Deifel wrote: > --- > utilities.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/utilities.c b/utilities.c > index 36298f7..8413c72 100644 > --- a/utilities.c > +++ b/utilities.c > @@ -380,6 +380,7 @@ build_taglist(const Arg *arg, FILE *f) { > k++; > } > if (in_tag) { > + t = 0; > while (marker < strlen(arg->s) && t < MAXTAGSIZE) foundtab[t++] = arg->s[marker++]; > foundtab[t] = '\0'; > fprintf(f, " [%s]", foundtab ); > -- This seems to have got overlooked in the recent update - it's only a small thing, but quite helpful. Could it please be considered for merging? Thanks, /J -- http://jasonwryan.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From hannes at yllr.net Fri Nov 12 23:30:57 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Sat, 13 Nov 2010 00:30:57 +0100 Subject: [Vimprobable-users] [PATCH] Don't concatenate the last two bookmark tags In-Reply-To: <20101112220825.GA12438@Archer> References: <1287431112-26978-1-git-send-email-hpdeifel@gmx.de> <20101112220825.GA12438@Archer> Message-ID: <20101112233056.GA25505@laptop2.lan.localhost> On Sat, Nov 13, 2010 at 11:08:25AM +1300, Jason Ryan wrote: > This seems to have got overlooked in the recent update - it's only a > small thing, but quite helpful. Could it please be considered for > merging? Oh, yes, sorry - especially to Hans-Peter! It seems I concentrated too much on the big patches and overlooked some of the smaller ones. Expect it to be merged tomorrow. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From nimrodomer at gmail.com Sat Nov 13 05:20:05 2010 From: nimrodomer at gmail.com (niemand) Date: Fri, 12 Nov 2010 21:20:05 -0800 (PST) Subject: [Vimprobable-users] Shift-yank limitation Message-ID: Hi there, I've found that yank (y) can be used to paste things pretty much globally, from the OOo word processor, to other instances of vimprobable2, etc. This is great for when I want to wget -r -n -np -k a website for offline usage. However, shift-y is much more limited, and can only be used across to other instances of vimprobable2. This goes for right-clicking "copy" as well. This kind of sucks, as it forces me to either spin up firefox or wget the page in order to use block quotes on papers I'm writing, etc. I haven't updated to the newer release of vimprobable, so I don't know if this limitation has been addressed yet, but in case it hasn't I wanted to bring it up. As an aside, is there a visual mode, as in vim, for vimprobable? I love navigating websites using the keyboard, but I always feel like I'm crashing from a high when I need to highlight text--which I can't copy and paste to other programs anyway, so it's not been a big problem lately anyway! Perhaps the problem is with my system? I use Ubuntu 10.04 & Vimprobable2 0.9.5.0. Thanks! From hannes at yllr.net Sat Nov 13 10:11:41 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 13 Nov 2010 11:11:41 +0100 Subject: [Vimprobable-users] Shift-yank limitation In-Reply-To: References: Message-ID: <20101113111141.4fc8c83f@workstation> Hi! niemand wrote: > However, shift-y is much more limited, > and can only be used across to other instances of vimprobable2. This > goes for right-clicking "copy" as well. This kind of sucks, as it > forces me to either spin up firefox or wget the page in order to use > block quotes on papers I'm writing, etc. Works for me. Since you're using Ubuntu with, I presume, Gnome, have you tried any of the common clipboard sharing solutions? > As an aside, is there a visual mode, as in vim, for vimprobable? I > love navigating websites using the keyboard, but I always feel like > I'm crashing from a high when I need to highlight text--which I can't > copy and paste to other programs anyway, so it's not been a big > problem lately anyway! What would you call a 'visual mode' in this case? You can highlight text with the keyboard (using caret mode) or with the mouse. Anything more to it? 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 Nov 13 10:45:30 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 13 Nov 2010 11:45:30 +0100 Subject: [Vimprobable-users] [PATCH] Don't concatenate the last two bookmark tags In-Reply-To: <1287431112-26978-1-git-send-email-hpdeifel@gmx.de> References: <1287431112-26978-1-git-send-email-hpdeifel@gmx.de> Message-ID: <20101113114530.0c72dee2@workstation> Merged and new version released. -------------- 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 Nov 13 12:00:11 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sat, 13 Nov 2010 12:00:11 +0000 Subject: [Vimprobable-users] Shift-yank limitation In-Reply-To: References: Message-ID: <20101113120009.GA5946@shuttle.home> On Fri, Nov 12, 2010 at 09:20:05PM -0800, niemand wrote: > Hi there, > > I've found that yank (y) can be used to paste things pretty much > globally, from the OOo word processor, to other instances of > vimprobable2, etc. This is great for when I want to wget -r -n -np > -k a website for offline usage. However, shift-y is much more > limited, and can only be used across to other instances of > vimprobable2. This goes for right-clicking "copy" as well. This kind > of sucks, as it forces me to either spin up firefox or wget the page > in order to use block quotes on papers I'm writing, etc. GTK clipboards are annoying. Look at using a program called "parcellite" -- and ensure when you run that, you set the following to on: Use Primary (Selection) Synchronize clipboards Then you should be 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 kasmra at vimprobable.mail.kapsi.fi Sat Nov 13 12:55:25 2010 From: kasmra at vimprobable.mail.kapsi.fi (Sami =?iso-8859-1?Q?M=E4ki?=) Date: Sat, 13 Nov 2010 14:55:25 +0200 Subject: [Vimprobable-users] Back/forward keys [revisited] Message-ID: <20101113125525.GA3242@debel> Hi, not trying to bitch about relatively minor issue here but still. *If* Vimprobable is at heart a Vim-like browser, in that case the default keybindings for back and forward should be Ctrl-o and Ctrl-i respectively. >From Vim help documentation: ----------------------------------------------------------------------- CTRL-O Go to [count] Older cursor position in jump list (not a motion command). {not in Vi} {not available without the |+jumplist| feature} CTRL-I Go to [count] newer cursor position in jump list (not a motion command). In a |quickfix-window| it takes you to the position of the error under the cursor. ----------------------------------------------------------------------- Cheers. -- Sami :wq From thomas at xteddy.org Sat Nov 13 12:58:22 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sat, 13 Nov 2010 12:58:22 +0000 Subject: [Vimprobable-users] Back/forward keys [revisited] In-Reply-To: <20101113125525.GA3242@debel> References: <20101113125525.GA3242@debel> Message-ID: <20101113125821.GB5946@shuttle.home> On Sat, Nov 13, 2010 at 02:55:25PM +0200, Sami M?ki wrote: > Hi, > > not trying to bitch about relatively minor issue here but still. *If* > Vimprobable is at heart a Vim-like browser, in that case the default > keybindings for back and forward should be Ctrl-o and Ctrl-i > respectively. > > From Vim help documentation: > > ----------------------------------------------------------------------- > CTRL-O Go to [count] Older cursor position in jump list > (not a motion command). {not in Vi} > {not available without the |+jumplist| feature} > > CTRL-I Go to [count] newer cursor position in jump list > (not a motion command). > In a |quickfix-window| it takes you to the position of > the error under the cursor. > ----------------------------------------------------------------------- If you're using Vimprobable2, you can change this at run time. I won't quote the manpage at you, but you can read about the navigation{Back,Forward} options in "man vimprobablerc". -- 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 kasmra at vimprobable.mail.kapsi.fi Sat Nov 13 13:13:02 2010 From: kasmra at vimprobable.mail.kapsi.fi (Sami =?iso-8859-1?Q?M=E4ki?=) Date: Sat, 13 Nov 2010 15:13:02 +0200 Subject: [Vimprobable-users] Back/forward keys [revisited] In-Reply-To: <20101113125821.GB5946@shuttle.home> References: <20101113125525.GA3242@debel> <20101113125821.GB5946@shuttle.home> Message-ID: <20101113131302.GA6713@debel> On Sat, Nov 13, 2010 at 12:58:22PM +0000, Thomas Adam wrote: > On Sat, Nov 13, 2010 at 02:55:25PM +0200, Sami M?ki wrote: > > Hi, > > > > not trying to bitch about relatively minor issue here but still. *If* > > Vimprobable is at heart a Vim-like browser, in that case the default > > keybindings for back and forward should be Ctrl-o and Ctrl-i > > respectively. > > > > If you're using Vimprobable2, you can change this at run time. I won't > quote the manpage at you, but you can read about the > navigation{Back,Forward} options in "man vimprobablerc". I'm using Vimprobable but going to check out the V2 as well. I think this (switching the default bindings) would be better for consistency but as said before, it's a no-biggie. Thanks. -- Sami :wq From niemand.is.no.one at gmail.com Sat Nov 13 16:02:29 2010 From: niemand.is.no.one at gmail.com (niemand) Date: Sat, 13 Nov 2010 08:02:29 -0800 (PST) Subject: [Vimprobable-users] Shift-yank limitation In-Reply-To: <20101113120009.GA5946@shuttle.home> References: <20101113120009.GA5946@shuttle.home> Message-ID: On Sat, 13 Nov 2010, Thomas Adam wrote: > On Fri, Nov 12, 2010 at 09:20:05PM -0800, niemand wrote: >> Hi there, >> >> I've found that yank (y) can be used to paste things pretty much >> globally, from the OOo word processor, to other instances of >> vimprobable2, etc. This is great for when I want to wget -r -n -np >> -k a website for offline usage. However, shift-y is much more >> limited, and can only be used across to other instances of >> vimprobable2. This goes for right-clicking "copy" as well. This kind >> of sucks, as it forces me to either spin up firefox or wget the page >> in order to use block quotes on papers I'm writing, etc. > > GTK clipboards are annoying. Look at using a program called "parcellite" -- > and ensure when you run that, you set the following to on: > > Use Primary (Selection) > Synchronize clipboards > > Then you should be OK. I've been playing with parcellite for the past 10 min's, and it works great as a workaround (it took a bit to figure out that if I want to paste in the command line, I have to copy using ctrl+shift+c). Thanks! > > -- 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.) > _______________________________________________ > Vimprobable-users mailing list > Vimprobable-users at vimprobable.org > http://vimprobable.org/mailman/listinfo/vimprobable-users > From niemand.is.no.one at gmail.com Sat Nov 13 16:08:02 2010 From: niemand.is.no.one at gmail.com (niemand) Date: Sat, 13 Nov 2010 08:08:02 -0800 (PST) Subject: [Vimprobable-users] Shift-yank limitation In-Reply-To: <20101113111141.4fc8c83f@workstation> References: <20101113111141.4fc8c83f@workstation> Message-ID: On Sat, 13 Nov 2010, Hannes Sch?ller wrote: > Hi! > > Works for me. Since you're using Ubuntu with, I presume, Gnome, have > you tried any of the common clipboard sharing solutions? I took Thomas' advice, so I'm set. > >> As an aside, is there a visual mode, as in vim, for vimprobable? I >> love navigating websites using the keyboard, but I always feel like >> I'm crashing from a high when I need to highlight text--which I can't >> copy and paste to other programs anyway, so it's not been a big >> problem lately anyway! > > What would you call a 'visual mode' in this case? You can highlight > text with the keyboard (using caret mode) or with the mouse. Anything > more to it? Sorry about that, I really wasn't being all that clear, was I... I meant 'visual mode' as in vim's visual-mode. That said, how do I enter caret mode? Thanks! -N > Hannes > From hannes at yllr.net Sat Nov 13 16:21:50 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 13 Nov 2010 17:21:50 +0100 Subject: [Vimprobable-users] Shift-yank limitation In-Reply-To: References: <20101113111141.4fc8c83f@workstation> Message-ID: <20101113172150.2d4e5263@workstation> niemand wrote: > >> As an aside, is there a visual mode, as in vim, for vimprobable? I > >> love navigating websites using the keyboard, but I always feel like > >> I'm crashing from a high when I need to highlight text--which I > >> can't copy and paste to other programs anyway, so it's not been a > >> big problem lately anyway! > > > > What would you call a 'visual mode' in this case? You can highlight > > text with the keyboard (using caret mode) or with the mouse. > > Anything more to it? > > Sorry about that, I really wasn't being all that clear, was I... I > meant 'visual mode' as in vim's visual-mode. That said, how do I > enter caret mode? :set caret=true See man vimprobablerc Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From niemand.is.no.one at gmail.com Sat Nov 13 16:49:38 2010 From: niemand.is.no.one at gmail.com (niemand) Date: Sat, 13 Nov 2010 08:49:38 -0800 (PST) Subject: [Vimprobable-users] Shift-yank limitation In-Reply-To: <20101113172150.2d4e5263@workstation> References: <20101113111141.4fc8c83f@workstation> <20101113172150.2d4e5263@workstation> Message-ID: On Sat, 13 Nov 2010, Hannes Sch?ller wrote: >> Sorry about that, I really wasn't being all that clear, was I... I >> meant 'visual mode' as in vim's visual-mode. That said, how do I >> enter caret mode? > > :set caret=true > > See man vimprobablerc Got it. In case someone else gets hung up on this, too: it took me a bit to figure out, but apparently when in caret mode, you need to hold & move the caret with the arrow keys. I don't know if there's a better way to cancel the highlighting, but a mouse click will do the trick. Thanks for the help, Hannes! > > Hannes > From robin.kreis at uni-bremen.de Sun Nov 14 09:39:59 2010 From: robin.kreis at uni-bremen.de (Robin Kreis) Date: Sun, 14 Nov 2010 10:39:59 +0100 Subject: [Vimprobable-users] Keys don't work when running ibus Message-ID: <20101114103959.96f50f03.robin.kreis@uni-bremen.de> Hi! Everything works fine without ibus. As soon as I run ibus-daemon, only the normal webkit keys (like up and down) work ('j' and 'f' don't). Other vimprobable2 bindings like 'o' don't work either. I can manually select the text field and enter :o (tab completion also works). Loading pages also works then. I have set XMODIFIERS=@im=ibus. ibus works fine with GTK (and even in vimprobable's text field). Greetings, Robin -- Schwitzt der Bauer unterm Arm, wird der Sommer wieder warm. From hannes at yllr.net Sun Nov 14 09:43:53 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sun, 14 Nov 2010 10:43:53 +0100 Subject: [Vimprobable-users] Keys don't work when running ibus In-Reply-To: <20101114103959.96f50f03.robin.kreis@uni-bremen.de> References: <20101114103959.96f50f03.robin.kreis@uni-bremen.de> Message-ID: <20101114104353.5f89ffd5@workstation> Hi! Robin Kreis wrote: > Everything works fine without ibus. As soon as I run ibus-daemon, > only the normal webkit keys (like up and down) work ('j' and 'f' > don't). Other vimprobable2 bindings like 'o' don't work either. I > can manually select the text field and enter :o (tab completion also > works). Loading pages also works then. > > I have set XMODIFIERS=@im=ibus. ibus works fine with GTK (and even in > vimprobable's text field). Could anyone who has ibus installed and running either confirm or refute this? Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From thomas at xteddy.org Sun Nov 14 11:20:46 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sun, 14 Nov 2010 11:20:46 +0000 Subject: [Vimprobable-users] Keys don't work when running ibus In-Reply-To: <20101114104353.5f89ffd5@workstation> References: <20101114103959.96f50f03.robin.kreis@uni-bremen.de> <20101114104353.5f89ffd5@workstation> Message-ID: <20101114112044.GA3667@shuttle.home> On Sun, Nov 14, 2010 at 10:43:53AM +0100, Hannes Sch?ller wrote: > Hi! > > Robin Kreis wrote: > > Everything works fine without ibus. As soon as I run ibus-daemon, > > only the normal webkit keys (like up and down) work ('j' and 'f' > > don't). Other vimprobable2 bindings like 'o' don't work either. I > > can manually select the text field and enter :o (tab completion also > > works). Loading pages also works then. > > > > I have set XMODIFIERS=@im=ibus. ibus works fine with GTK (and even in > > vimprobable's text field). > > Could anyone who has ibus installed and running either confirm or > refute this? Seems bogus to me -- everthing works fine. As I would expect, BTW, given how ibus works. -- 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 robin.kreis at uni-bremen.de Sun Nov 14 11:47:10 2010 From: robin.kreis at uni-bremen.de (Robin Kreis) Date: Sun, 14 Nov 2010 12:47:10 +0100 Subject: [Vimprobable-users] Keys don't work when running ibus In-Reply-To: <20101114112044.GA3667@shuttle.home> References: <20101114103959.96f50f03.robin.kreis@uni-bremen.de> <20101114104353.5f89ffd5@workstation> <20101114112044.GA3667@shuttle.home> Message-ID: <20101114124710.4fe87ac1.robin.kreis@uni-bremen.de> On Sun, 14 Nov 2010 11:20:46 +0000 Thomas Adam wrote: > On Sun, Nov 14, 2010 at 10:43:53AM +0100, Hannes Sch?ller wrote: > > Hi! > > > > Robin Kreis wrote: > > > Everything works fine without ibus. As soon as I run ibus-daemon, > > > only the normal webkit keys (like up and down) work ('j' and 'f' > > > don't). Other vimprobable2 bindings like 'o' don't work either. I > > > can manually select the text field and enter :o (tab completion also > > > works). Loading pages also works then. > > > > > > I have set XMODIFIERS=@im=ibus. ibus works fine with GTK (and even in > > > vimprobable's text field). > > > > Could anyone who has ibus installed and running either confirm or > > refute this? > > Seems bogus to me -- everthing works fine. As I would expect, BTW, given > how ibus works. I tried using gnome with another user on the same computer (I use wmii with no DE), with the same results. I also tried a different computer running gnome and ibus with the same results. They all run arch. I can't see the next steps in understanding this issue, but I hope one of you can. -- Fehlt der Knecht am Morgen st?ndig, ist die Magd nachts zu lebendig. From thomas at xteddy.org Sun Nov 14 16:02:39 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sun, 14 Nov 2010 16:02:39 +0000 Subject: [Vimprobable-users] Keys don't work when running ibus In-Reply-To: <20101114124710.4fe87ac1.robin.kreis@uni-bremen.de> References: <20101114103959.96f50f03.robin.kreis@uni-bremen.de> <20101114104353.5f89ffd5@workstation> <20101114112044.GA3667@shuttle.home> <20101114124710.4fe87ac1.robin.kreis@uni-bremen.de> Message-ID: <20101114160237.GA3612@shuttle.home> On Sun, Nov 14, 2010 at 12:47:10PM +0100, Robin Kreis wrote: > On Sun, 14 Nov 2010 11:20:46 +0000 > Thomas Adam wrote: > > > On Sun, Nov 14, 2010 at 10:43:53AM +0100, Hannes Sch?ller wrote: > > > Hi! > > > > > > Robin Kreis wrote: > > > > Everything works fine without ibus. As soon as I run ibus-daemon, > > > > only the normal webkit keys (like up and down) work ('j' and 'f' > > > > don't). Other vimprobable2 bindings like 'o' don't work either. I > > > > can manually select the text field and enter :o (tab completion also > > > > works). Loading pages also works then. > > > > > > > > I have set XMODIFIERS=@im=ibus. ibus works fine with GTK (and even in > > > > vimprobable's text field). > > > > > > Could anyone who has ibus installed and running either confirm or > > > refute this? > > > > Seems bogus to me -- everthing works fine. As I would expect, BTW, given > > how ibus works. > > I tried using gnome with another user on the same computer (I use wmii > with no DE), with the same results. I also tried a different computer > running gnome and ibus with the same results. They all run arch. I > can't see the next steps in understanding this issue, but I hope one of > you can. Kill ibus. Attach xev to the Vimprobable window, and press 'j', then 'f'. Record the output from xev -- this is important. Then start ibus-daemon, re-attach xev to the same Vimprobable window and repeat the test above, pressing 'j' and 'f'. Record the output. Send the results here. -- 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 robin.kreis at uni-bremen.de Sun Nov 14 16:56:32 2010 From: robin.kreis at uni-bremen.de (Robin Kreis) Date: Sun, 14 Nov 2010 17:56:32 +0100 Subject: [Vimprobable-users] Keys don't work when running ibus In-Reply-To: <20101114160237.GA3612@shuttle.home> References: <20101114103959.96f50f03.robin.kreis@uni-bremen.de> <20101114104353.5f89ffd5@workstation> <20101114112044.GA3667@shuttle.home> <20101114124710.4fe87ac1.robin.kreis@uni-bremen.de> <20101114160237.GA3612@shuttle.home> Message-ID: <20101114175632.a536aa5c.robin.kreis@uni-bremen.de> On Sun, 14 Nov 2010 16:02:39 +0000 Thomas Adam wrote: > On Sun, Nov 14, 2010 at 12:47:10PM +0100, Robin Kreis wrote: > > On Sun, 14 Nov 2010 11:20:46 +0000 > > Thomas Adam wrote: > > > > > On Sun, Nov 14, 2010 at 10:43:53AM +0100, Hannes Sch?ller wrote: > > > > Hi! > > > > > > > > Robin Kreis wrote: > > > > > Everything works fine without ibus. As soon as I run ibus-daemon, > > > > > only the normal webkit keys (like up and down) work ('j' and 'f' > > > > > don't). Other vimprobable2 bindings like 'o' don't work either. I > > > > > can manually select the text field and enter :o (tab completion also > > > > > works). Loading pages also works then. > > > > > > > > > > I have set XMODIFIERS=@im=ibus. ibus works fine with GTK (and even in > > > > > vimprobable's text field). > > > > > > > > Could anyone who has ibus installed and running either confirm or > > > > refute this? > > > > > > Seems bogus to me -- everthing works fine. As I would expect, BTW, given > > > how ibus works. > > > > I tried using gnome with another user on the same computer (I use wmii > > with no DE), with the same results. I also tried a different computer > > running gnome and ibus with the same results. They all run arch. I > > can't see the next steps in understanding this issue, but I hope one of > > you can. > > Kill ibus. Attach xev to the Vimprobable window, and press 'j', then 'f'. > Record the output from xev -- this is important. Then start ibus-daemon, > re-attach xev to the same Vimprobable window and repeat the test above, > pressing 'j' and 'f'. Record the output. > > Send the results here. Odd. The xev output seems to be exactly the same with and without ibus-daemon running. Both are attached for the sake of completeness. I will add some debug messages in vimprobable2's key handlers and post any results I get. -- Dem Alltagsstre? kannst Du entgeh'n, vermeidest du es aufzusteh'n. -------------- next part -------------- A non-text attachment was scrubbed... Name: xev_with_ibus Type: application/octet-stream Size: 3473 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: xev_without_ibus Type: application/octet-stream Size: 3473 bytes Desc: not available URL: From thomas at xteddy.org Sun Nov 14 17:11:18 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sun, 14 Nov 2010 17:11:18 +0000 Subject: [Vimprobable-users] Keys don't work when running ibus In-Reply-To: <20101114175632.a536aa5c.robin.kreis@uni-bremen.de> References: <20101114103959.96f50f03.robin.kreis@uni-bremen.de> <20101114104353.5f89ffd5@workstation> <20101114112044.GA3667@shuttle.home> <20101114124710.4fe87ac1.robin.kreis@uni-bremen.de> <20101114160237.GA3612@shuttle.home> <20101114175632.a536aa5c.robin.kreis@uni-bremen.de> Message-ID: <20101114171117.GB3612@shuttle.home> On Sun, Nov 14, 2010 at 05:56:32PM +0100, Robin Kreis wrote: > On Sun, 14 Nov 2010 16:02:39 +0000 > Thomas Adam wrote: > > > On Sun, Nov 14, 2010 at 12:47:10PM +0100, Robin Kreis wrote: > > > On Sun, 14 Nov 2010 11:20:46 +0000 > > > Thomas Adam wrote: > > > > > > > On Sun, Nov 14, 2010 at 10:43:53AM +0100, Hannes Sch?ller wrote: > > > > > Hi! > > > > > > > > > > Robin Kreis wrote: > > > > > > Everything works fine without ibus. As soon as I run ibus-daemon, > > > > > > only the normal webkit keys (like up and down) work ('j' and 'f' > > > > > > don't). Other vimprobable2 bindings like 'o' don't work either. I > > > > > > can manually select the text field and enter :o (tab completion also > > > > > > works). Loading pages also works then. > > > > > > > > > > > > I have set XMODIFIERS=@im=ibus. ibus works fine with GTK (and even in > > > > > > vimprobable's text field). > > > > > > > > > > Could anyone who has ibus installed and running either confirm or > > > > > refute this? > > > > > > > > Seems bogus to me -- everthing works fine. As I would expect, BTW, given > > > > how ibus works. > > > > > > I tried using gnome with another user on the same computer (I use wmii > > > with no DE), with the same results. I also tried a different computer > > > running gnome and ibus with the same results. They all run arch. I > > > can't see the next steps in understanding this issue, but I hope one of > > > you can. > > > > Kill ibus. Attach xev to the Vimprobable window, and press 'j', then 'f'. > > Record the output from xev -- this is important. Then start ibus-daemon, > > re-attach xev to the same Vimprobable window and repeat the test above, > > pressing 'j' and 'f'. Record the output. > > > > Send the results here. > > Odd. The xev output seems to be exactly the same with and without > ibus-daemon running. Both are attached for the sake of completeness. Which means that the Vimprobable window receives the event (i.e., something else hasn't eaten it already). > I will add some debug messages in vimprobable2's key handlers and post > any results I get. I wouldn't bother; it won't tell you much. I just hope this isn't related to you setting PASS THROUGH mode and simply not realising. -- 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 robin.kreis at uni-bremen.de Sun Nov 14 17:13:22 2010 From: robin.kreis at uni-bremen.de (Robin Kreis) Date: Sun, 14 Nov 2010 18:13:22 +0100 Subject: [Vimprobable-users] Keys don't work when running ibus In-Reply-To: <20101114175632.a536aa5c.robin.kreis@uni-bremen.de> References: <20101114103959.96f50f03.robin.kreis@uni-bremen.de> <20101114104353.5f89ffd5@workstation> <20101114112044.GA3667@shuttle.home> <20101114124710.4fe87ac1.robin.kreis@uni-bremen.de> <20101114160237.GA3612@shuttle.home> <20101114175632.a536aa5c.robin.kreis@uni-bremen.de> Message-ID: <20101114181322.f515bba3.robin.kreis@uni-bremen.de> > I will add some debug messages in vimprobable2's key handlers and post > any results I get. I made process_keypress output CLEAN(event->state) and event->keyval. Without ibus, simply pressing j results in a state of 0 and a keyval of 106. With ibus-daemon running, event->keyval stays the same but CLEAN (event->state) is 33554432 (1<<25). Quoting from gdktypes.h: /* The next few modifiers are used by XKB, so we skip to the end. * Bits 15 - 25 are currently unused. Bit 29 is used internally. */ Although I can't explain why unused bits are set, I guess the CLEAN macro should also include & GDK_MODIFIER_MASK. If it helps, I'll create a patch for that. -- Sollten Ochs und K?he rennen, wird der ganze Stall wohl brennen. From thomas at xteddy.org Sun Nov 14 17:16:56 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sun, 14 Nov 2010 17:16:56 +0000 Subject: [Vimprobable-users] Keys don't work when running ibus In-Reply-To: <20101114181322.f515bba3.robin.kreis@uni-bremen.de> References: <20101114103959.96f50f03.robin.kreis@uni-bremen.de> <20101114104353.5f89ffd5@workstation> <20101114112044.GA3667@shuttle.home> <20101114124710.4fe87ac1.robin.kreis@uni-bremen.de> <20101114160237.GA3612@shuttle.home> <20101114175632.a536aa5c.robin.kreis@uni-bremen.de> <20101114181322.f515bba3.robin.kreis@uni-bremen.de> Message-ID: <20101114171655.GC3612@shuttle.home> On Sun, Nov 14, 2010 at 06:13:22PM +0100, Robin Kreis wrote: > Although I can't explain why unused bits are set, I guess the CLEAN > macro should also include & GDK_MODIFIER_MASK. If it helps, I'll create > a patch for that. No! This is a bad thing to do, and is going to break a lot of events involving any modifier which might be on -- and where the interception of it (be it at the WM-level or otherwise) won't understand the extra information that's stripped. (Specifically I am referring to Numlock, Scroll lock, etc.) What's more interesting -- and the question you should be asking is why it seems to work fine for me, and not for you -- so what is it about ibus for yourself and me which differs? -- 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 robin.kreis at uni-bremen.de Sun Nov 14 18:02:24 2010 From: robin.kreis at uni-bremen.de (Robin Kreis) Date: Sun, 14 Nov 2010 19:02:24 +0100 Subject: [Vimprobable-users] Keys don't work when running ibus In-Reply-To: <20101114171655.GC3612@shuttle.home> References: <20101114103959.96f50f03.robin.kreis@uni-bremen.de> <20101114104353.5f89ffd5@workstation> <20101114112044.GA3667@shuttle.home> <20101114124710.4fe87ac1.robin.kreis@uni-bremen.de> <20101114160237.GA3612@shuttle.home> <20101114175632.a536aa5c.robin.kreis@uni-bremen.de> <20101114181322.f515bba3.robin.kreis@uni-bremen.de> <20101114171655.GC3612@shuttle.home> Message-ID: <20101114190224.b767aa4f.robin.kreis@uni-bremen.de> On Sun, 14 Nov 2010 17:16:56 +0000 Thomas Adam wrote: > On Sun, Nov 14, 2010 at 06:13:22PM +0100, Robin Kreis wrote: > > Although I can't explain why unused bits are set, I guess the CLEAN > > macro should also include & GDK_MODIFIER_MASK. If it helps, I'll create > > a patch for that. > > No! This is a bad thing to do, and is going to break a lot of events > involving any modifier which might be on -- and where the interception of it > (be it at the WM-level or otherwise) won't understand the extra information > that's stripped. (Specifically I am referring to Numlock, Scroll lock, > etc.) > > What's more interesting -- and the question you should be asking is why it > seems to work fine for me, and not for you -- so what is it about ibus for > yourself and me which differs? What? The CLEAN macro in vimprobable2's main.c already strips mouse buttons and GDK_MOD2_MASK. It doesn't strip the unused GdkModifierType bits. That macro isn't used to alter any events, but simply for comparing the event's modifiers. A simple example from the vimprobable2 source code is CLEAN(event->state) == 0. As CLEAN(event->state) still contains unused bits, the comparison fails as soon as the mask has any of those unused bits set - so vimprobable2 assumes that the unused (and the internally used) bits are set to zero. To clarify, I'm not suggesting stripping the bits set in GDK_MODIFIER_MASK but to strip those not set in it - which are the unused and internal ones. ibus (or gdk) certainly shows a different behaviour on this and your machine. By the way, I'm running ibus 1.3.8 and gtk2 2.22.0. But I don't think it's an error if any of the unused or internal bits in GdkModifierType are not zero - so I don't think it should be fixed there. Bottom line: I think vimprobable2 should ignore unused and internal GdkModifierType bits instead of assuming that they're zero. The CLEAN macro seems like the right place to do it to me, since other modifier bits are also filtered out there. -- Wer dienstags erst zur Arbeit rennt, hat den Montag voll verpennt. From hannes at yllr.net Sun Nov 14 18:03:14 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Sun, 14 Nov 2010 19:03:14 +0100 Subject: [Vimprobable-users] Keys don't work when running ibus In-Reply-To: <20101114190224.b767aa4f.robin.kreis@uni-bremen.de> References: <20101114103959.96f50f03.robin.kreis@uni-bremen.de> <20101114104353.5f89ffd5@workstation> <20101114112044.GA3667@shuttle.home> <20101114124710.4fe87ac1.robin.kreis@uni-bremen.de> <20101114160237.GA3612@shuttle.home> <20101114175632.a536aa5c.robin.kreis@uni-bremen.de> <20101114181322.f515bba3.robin.kreis@uni-bremen.de> <20101114171655.GC3612@shuttle.home> <20101114190224.b767aa4f.robin.kreis@uni-bremen.de> Message-ID: <20101114180313.GC25505@laptop2.lan.localhost> On Sun, Nov 14, 2010 at 07:02:24PM +0100, Robin Kreis wrote: > To clarify, I'm not suggesting stripping the bits set in > GDK_MODIFIER_MASK but to strip those not set in it - which are the > unused and internal ones. To be honest, I don't see a problem with that solution. I also don't know why anything would set anything to them, but avoiding undefined states sounds like a good idea to me. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From thomas at xteddy.org Sun Nov 14 18:05:56 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sun, 14 Nov 2010 18:05:56 +0000 Subject: [Vimprobable-users] Keys don't work when running ibus In-Reply-To: <20101114190224.b767aa4f.robin.kreis@uni-bremen.de> References: <20101114103959.96f50f03.robin.kreis@uni-bremen.de> <20101114104353.5f89ffd5@workstation> <20101114112044.GA3667@shuttle.home> <20101114124710.4fe87ac1.robin.kreis@uni-bremen.de> <20101114160237.GA3612@shuttle.home> <20101114175632.a536aa5c.robin.kreis@uni-bremen.de> <20101114181322.f515bba3.robin.kreis@uni-bremen.de> <20101114171655.GC3612@shuttle.home> <20101114190224.b767aa4f.robin.kreis@uni-bremen.de> Message-ID: <20101114180554.GD3612@shuttle.home> On Sun, Nov 14, 2010 at 07:02:24PM +0100, Robin Kreis wrote: > To clarify, I'm not suggesting stripping the bits set in > GDK_MODIFIER_MASK but to strip those not set in it - which are the > unused and internal ones. I understand that. Send a patch in, and when it breaks, we'll know to revert it. And break things it will, unfortunately. -- 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 robin.kreis at uni-bremen.de Sun Nov 14 18:20:14 2010 From: robin.kreis at uni-bremen.de (Robin Kreis) Date: Sun, 14 Nov 2010 19:20:14 +0100 Subject: [Vimprobable-users] [PATCH] Ignore event->state bits not set in GdkEventMask Message-ID: <20101114192014.474ae2af.robin.kreis@uni-bremen.de> Under unknown circumstances (some computers running ibus), event->state is 1<<25 (an unused bit) instead of 0. This patch modifies the CLEAN macro to strip those unused bits, making vimprobable ignore them. This fixes a bug where, on some machines, vimprobable wouldn't accept any keys while ibus-daemon is running. --- main.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/main.c b/main.c index 74a5b57..22e1582 100644 --- a/main.c +++ b/main.c @@ -16,7 +16,7 @@ #include "javascript.h" /* remove numlock symbol from keymask */ -#define CLEAN(mask) (mask & ~(GDK_MOD2_MASK) & ~(GDK_BUTTON1_MASK) & ~ (GDK_BUTTON2_MASK) & ~(GDK_BUTTON3_MASK) & ~(GDK_BUTTON4_MASK) & ~ (GDK_BUTTON5_MASK)) +#define CLEAN(mask) (mask & (GDK_MODIFIER_MASK) & ~ (GDK_MOD2_MASK) & ~(GDK_BUTTON1_MASK) & ~(GDK_BUTTON2_MASK) & ~ (GDK_BUTTON3_MASK) & ~(GDK_BUTTON4_MASK) & ~(GDK_BUTTON5_MASK)) /* callbacks here */ static void inputbox_activate_cb(GtkEntry *entry, gpointer user_data); -- 1.7.3.2 From robin.kreis at uni-bremen.de Sun Nov 14 18:22:17 2010 From: robin.kreis at uni-bremen.de (Robin Kreis) Date: Sun, 14 Nov 2010 19:22:17 +0100 Subject: [Vimprobable-users] [PATCH] Ignore event->state bits not set in GdkEventMask Message-ID: <20101114192217.c76887f6.robin.kreis@uni-bremen.de> Under unknown circumstances (some computers running ibus), event->state is 1<<25 (an unused bit) instead of 0. This patch modifies the CLEAN macro to strip those unused bits, making vimprobable ignore them. This fixes a bug where, on some machines, vimprobable wouldn't accept any keys while ibus-daemon is running. --- main.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/main.c b/main.c index 74a5b57..22e1582 100644 --- a/main.c +++ b/main.c @@ -16,7 +16,7 @@ #include "javascript.h" /* remove numlock symbol from keymask */ -#define CLEAN(mask) (mask & ~(GDK_MOD2_MASK) & ~(GDK_BUTTON1_MASK) & ~(GDK_BUTTON2_MASK) & ~(GDK_BUTTON3_MASK) & ~(GDK_BUTTON4_MASK) & ~(GDK_BUTTON5_MASK)) +#define CLEAN(mask) (mask & (GDK_MODIFIER_MASK) & ~(GDK_MOD2_MASK) & ~(GDK_BUTTON1_MASK) & ~(GDK_BUTTON2_MASK) & ~(GDK_BUTTON3_MASK) & ~(GDK_BUTTON4_MASK) & ~(GDK_BUTTON5_MASK)) /* callbacks here */ static void inputbox_activate_cb(GtkEntry *entry, gpointer user_data); -- 1.7.3.2 From robin.kreis at uni-bremen.de Sun Nov 14 18:24:43 2010 From: robin.kreis at uni-bremen.de (Robin Kreis) Date: Sun, 14 Nov 2010 19:24:43 +0100 Subject: [Vimprobable-users] [PATCH] Ignore event->state bits not set in GdkEventMask In-Reply-To: <20101114192014.474ae2af.robin.kreis@uni-bremen.de> References: <20101114192014.474ae2af.robin.kreis@uni-bremen.de> Message-ID: <20101114192443.ed8dfcc5.robin.kreis@uni-bremen.de> Oops. My MUA did a great job breaking that one. -- Steht der Bauer im Gem?se, hat er sp?ter gr?ne F??e. From thomas at xteddy.org Sun Nov 14 18:33:43 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sun, 14 Nov 2010 18:33:43 +0000 Subject: [Vimprobable-users] [PATCH] Ignore event->state bits not set in GdkEventMask In-Reply-To: <20101114192217.c76887f6.robin.kreis@uni-bremen.de> References: <20101114192217.c76887f6.robin.kreis@uni-bremen.de> Message-ID: <20101114183342.GE3612@shuttle.home> On Sun, Nov 14, 2010 at 07:22:17PM +0100, Robin Kreis wrote: > Under unknown circumstances (some computers running ibus), event->state > is 1<<25 (an unused bit) instead of 0. This patch modifies the CLEAN > macro to strip those unused bits, making vimprobable ignore them. > > This fixes a bug where, on some machines, vimprobable wouldn't accept > any keys while ibus-daemon is running. > --- > main.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/main.c b/main.c > index 74a5b57..22e1582 100644 > --- a/main.c > +++ b/main.c > @@ -16,7 +16,7 @@ > #include "javascript.h" > > /* remove numlock symbol from keymask */ This comment is now bogus -- needs updating. > -#define CLEAN(mask) (mask & ~(GDK_MOD2_MASK) & ~(GDK_BUTTON1_MASK) & ~(GDK_BUTTON2_MASK) & ~(GDK_BUTTON3_MASK) & ~(GDK_BUTTON4_MASK) & ~(GDK_BUTTON5_MASK)) > +#define CLEAN(mask) (mask & (GDK_MODIFIER_MASK) & ~(GDK_MOD2_MASK) & ~(GDK_BUTTON1_MASK) & ~(GDK_BUTTON2_MASK) & ~(GDK_BUTTON3_MASK) & ~(GDK_BUTTON4_MASK) & ~(GDK_BUTTON5_MASK)) Also, this is getting rather unweildy. I think splitting this up a little is easier in the long run: #define CLEAN_MOD_MASK (GDK_MOD2_MASK|GDK_MODIFIER_MASK) #define CLEAN_MOD_BUTTON_MASK (GDK_BUTTON1_MASK|GDK_BUTTON2_MASK|GDK_BUTTON3_MASK|GDK_BUTTON4_MASK|GDK_BUTTON5_MASK) #define CLEAN(mask) (mask &~ CLEAN_MOD_MASK &~ CLEAN_MOD_BUTTON_MASK) ... or some such. I've obviously not tested this. Robin -- can you do this? If not, I'll have to later on tomorrow. -- 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 robin.kreis at uni-bremen.de Sun Nov 14 18:53:21 2010 From: robin.kreis at uni-bremen.de (Robin Kreis) Date: Sun, 14 Nov 2010 19:53:21 +0100 Subject: [Vimprobable-users] [PATCH v2 1/1] Ignore event->state bits not set in GdkEventMask Message-ID: <1289760801-4181-1-git-send-email-robin.kreis@uni-bremen.de> Under unknown circumstances (some computers running ibus), event->state is 1<<25 (an unused bit) instead of 0. This patch modifies the CLEAN macro to strip those unused bits, making vimprobable ignore them. This fixes a bug where, on some machines, vimprobable wouldn't accept any keys while ibus-daemon is running. --- main.c | 11 +++++++++-- 1 files changed, 9 insertions(+), 2 deletions(-) diff --git a/main.c b/main.c index 74a5b57..471ea60 100644 --- a/main.c +++ b/main.c @@ -15,8 +15,15 @@ #include "callbacks.h" #include "javascript.h" -/* remove numlock symbol from keymask */ -#define CLEAN(mask) (mask & ~(GDK_MOD2_MASK) & ~(GDK_BUTTON1_MASK) & ~(GDK_BUTTON2_MASK) & ~(GDK_BUTTON3_MASK) & ~(GDK_BUTTON4_MASK) & ~(GDK_BUTTON5_MASK)) +/* the unused GdkModifierType bits are set */ +#define CLEAN_MOD_UNUSED_MASK (~(GDK_MODIFIER_MASK)) + +#define CLEAN_MOD_NUMLOCK_MASK (GDK_MOD2_MASK) + +#define CLEAN_MOD_BUTTON_MASK (GDK_BUTTON1_MASK|GDK_BUTTON2_MASK|GDK_BUTTON3_MASK|GDK_BUTTON4_MASK|GDK_BUTTON5_MASK) + +/* remove unused bits, numlock symbol and buttons from keymask */ +#define CLEAN(mask) (mask & ~(CLEAN_MOD_UNUSED_MASK) & ~(CLEAN_MOD_NUMLOCK_MASK) & ~(CLEAN_MOD_BUTTON_MASK)) /* callbacks here */ static void inputbox_activate_cb(GtkEntry *entry, gpointer user_data); -- 1.7.3.2 From thomas at xteddy.org Sun Nov 14 19:04:10 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sun, 14 Nov 2010 19:04:10 +0000 Subject: [Vimprobable-users] [PATCH v2 1/1] Ignore event->state bits not set in GdkEventMask In-Reply-To: <1289760801-4181-1-git-send-email-robin.kreis@uni-bremen.de> References: <1289760801-4181-1-git-send-email-robin.kreis@uni-bremen.de> Message-ID: <20101114190409.GA2538@debian> On Sun, Nov 14, 2010 at 07:53:21PM +0100, Robin Kreis wrote: > Under unknown circumstances (some computers running ibus), event->state > is 1<<25 (an unused bit) instead of 0. This patch modifies the CLEAN > macro to strip those unused bits, making vimprobable ignore them. > > This fixes a bug where, on some machines, vimprobable wouldn't accept > any keys while ibus-daemon is running. Does ibus need mentioning here? Don't think so. > --- > main.c | 11 +++++++++-- > 1 files changed, 9 insertions(+), 2 deletions(-) > > diff --git a/main.c b/main.c > index 74a5b57..471ea60 100644 > --- a/main.c > +++ b/main.c > @@ -15,8 +15,15 @@ > #include "callbacks.h" > #include "javascript.h" > > -/* remove numlock symbol from keymask */ > -#define CLEAN(mask) (mask & ~(GDK_MOD2_MASK) & ~(GDK_BUTTON1_MASK) & ~(GDK_BUTTON2_MASK) & ~(GDK_BUTTON3_MASK) & ~(GDK_BUTTON4_MASK) & ~(GDK_BUTTON5_MASK)) > +/* the unused GdkModifierType bits are set */ > +#define CLEAN_MOD_UNUSED_MASK (~(GDK_MODIFIER_MASK)) Do you really mean "~" here? It's already being used like that in CLEAN. Otherwise it looks OK. -- Thomas Adam -- "It was the cruelest game I've ever played and it's played inside my head." -- "Hush The Warmth", Gorky's Zygotic Mynci. From hannes at yllr.net Sun Nov 14 19:06:22 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Sun, 14 Nov 2010 20:06:22 +0100 Subject: [Vimprobable-users] [PATCH v2 1/1] Ignore event->state bits not set in GdkEventMask In-Reply-To: <20101114190409.GA2538@debian> References: <1289760801-4181-1-git-send-email-robin.kreis@uni-bremen.de> <20101114190409.GA2538@debian> Message-ID: <20101114190621.GD25505@laptop2.lan.localhost> On Sun, Nov 14, 2010 at 07:04:10PM +0000, Thomas Adam wrote: > On Sun, Nov 14, 2010 at 07:53:21PM +0100, Robin Kreis wrote: > > Under unknown circumstances (some computers running ibus), event->state > > is 1<<25 (an unused bit) instead of 0. This patch modifies the CLEAN > > macro to strip those unused bits, making vimprobable ignore them. > > > > This fixes a bug where, on some machines, vimprobable wouldn't accept > > any keys while ibus-daemon is running. > > Does ibus need mentioning here? Yes, because that was the reason for this patch. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From robin.kreis at uni-bremen.de Sun Nov 14 19:18:51 2010 From: robin.kreis at uni-bremen.de (Robin Kreis) Date: Sun, 14 Nov 2010 20:18:51 +0100 Subject: [Vimprobable-users] [PATCH v2 1/1] Ignore event->state bits not set in GdkEventMask In-Reply-To: <20101114190409.GA2538@debian> References: <1289760801-4181-1-git-send-email-robin.kreis@uni-bremen.de> <20101114190409.GA2538@debian> Message-ID: <20101114201851.0c1f728b.robin.kreis@uni-bremen.de> On Sun, 14 Nov 2010 19:04:10 +0000 Thomas Adam wrote: > On Sun, Nov 14, 2010 at 07:53:21PM +0100, Robin Kreis wrote: > > Under unknown circumstances (some computers running ibus), event->state > > is 1<<25 (an unused bit) instead of 0. This patch modifies the CLEAN > > macro to strip those unused bits, making vimprobable ignore them. > > > > This fixes a bug where, on some machines, vimprobable wouldn't accept > > any keys while ibus-daemon is running. > > Does ibus need mentioning here? Don't think so. I mentioned it because it's hopefully the only situation where the patch makes a difference. > > --- > > main.c | 11 +++++++++-- > > 1 files changed, 9 insertions(+), 2 deletions(-) > > > > diff --git a/main.c b/main.c > > index 74a5b57..471ea60 100644 > > --- a/main.c > > +++ b/main.c > > @@ -15,8 +15,15 @@ > > #include "callbacks.h" > > #include "javascript.h" > > > > -/* remove numlock symbol from keymask */ > > -#define CLEAN(mask) (mask & ~(GDK_MOD2_MASK) & ~(GDK_BUTTON1_MASK) & ~(GDK_BUTTON2_MASK) & ~(GDK_BUTTON3_MASK) & ~(GDK_BUTTON4_MASK) & ~(GDK_BUTTON5_MASK)) > > +/* the unused GdkModifierType bits are set */ > > +#define CLEAN_MOD_UNUSED_MASK (~(GDK_MODIFIER_MASK)) > > Do you really mean "~" here? It's already being used like that in CLEAN. I do. GDK_MODIFIER_MASK has all the modifier bits set and the others unset. It is being negated twice for consistency: CLEAN_MOD_UNUSED_MASK has all the bits we want to strip set, just like the other masks. I will add another comment to make this clearer. > Otherwise it looks OK. I'm glad to hear that. -- Ist die Viehzucht aufgegeben, hei?t es von Touristen leben. From thomas at xteddy.org Sun Nov 14 19:21:32 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sun, 14 Nov 2010 19:21:32 +0000 Subject: [Vimprobable-users] [PATCH v2 1/1] Ignore event->state bits not set in GdkEventMask In-Reply-To: <20101114201851.0c1f728b.robin.kreis@uni-bremen.de> References: <1289760801-4181-1-git-send-email-robin.kreis@uni-bremen.de> <20101114190409.GA2538@debian> <20101114201851.0c1f728b.robin.kreis@uni-bremen.de> Message-ID: <20101114192131.GB2538@debian> On Sun, Nov 14, 2010 at 08:18:51PM +0100, Robin Kreis wrote: > I do. GDK_MODIFIER_MASK has all the modifier bits set and the others > unset. It is being negated twice for consistency: I was thinking more if that macro was ever used for anything else, where the behaviour might differ (leading to unnecessary bit-twiddling elsewhere to make it sane.) -- Thomas Adam -- "It was the cruelest game I've ever played and it's played inside my head." -- "Hush The Warmth", Gorky's Zygotic Mynci. From robin.kreis at uni-bremen.de Sun Nov 14 19:27:49 2010 From: robin.kreis at uni-bremen.de (Robin Kreis) Date: Sun, 14 Nov 2010 20:27:49 +0100 Subject: [Vimprobable-users] [PATCH v2 1/1] Ignore event->state bits not set in GdkEventMask In-Reply-To: <20101114192131.GB2538@debian> References: <1289760801-4181-1-git-send-email-robin.kreis@uni-bremen.de> <20101114190409.GA2538@debian> <20101114201851.0c1f728b.robin.kreis@uni-bremen.de> <20101114192131.GB2538@debian> Message-ID: <20101114202749.d3a9f6a7.robin.kreis@uni-bremen.de> On Sun, 14 Nov 2010 19:21:32 +0000 Thomas Adam wrote: > On Sun, Nov 14, 2010 at 08:18:51PM +0100, Robin Kreis wrote: > > I do. GDK_MODIFIER_MASK has all the modifier bits set and the others > > unset. It is being negated twice for consistency: > > I was thinking more if that macro was ever used for anything else, where the > behaviour might differ (leading to unnecessary bit-twiddling elsewhere to > make it sane.) I can't see the point of reusing a macro that just "wraps" another constant. Actually, I guess I will completely drop that one and just use GDK_MODIFIER_MASK. -- Friert im J?nner Stein und Bein, k?nnte es der Winter sein. From robin.kreis at uni-bremen.de Sun Nov 14 19:43:18 2010 From: robin.kreis at uni-bremen.de (Robin Kreis) Date: Sun, 14 Nov 2010 20:43:18 +0100 Subject: [Vimprobable-users] [PATCH v3 1/1] Ignore event->state bits not set in GdkEventMask Message-ID: <1289763798-16555-1-git-send-email-robin.kreis@uni-bremen.de> Under unknown circumstances (like some computers running ibus), event->state is 1<<25 (an unused bit) instead of 0. This patch modifies the CLEAN macro to strip those unused bits, making vimprobable ignore them. This fixes a bug where, on those machines, vimprobable wouldn't accept any keys. --- main.c | 8 ++++++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/main.c b/main.c index 74a5b57..214edaf 100644 --- a/main.c +++ b/main.c @@ -15,8 +15,12 @@ #include "callbacks.h" #include "javascript.h" -/* remove numlock symbol from keymask */ -#define CLEAN(mask) (mask & ~(GDK_MOD2_MASK) & ~(GDK_BUTTON1_MASK) & ~(GDK_BUTTON2_MASK) & ~(GDK_BUTTON3_MASK) & ~(GDK_BUTTON4_MASK) & ~(GDK_BUTTON5_MASK)) +/* the CLEAN_MOD_*_MASK defines have all the bits set that will be stripped from the modifier bit field */ +#define CLEAN_MOD_NUMLOCK_MASK (GDK_MOD2_MASK) +#define CLEAN_MOD_BUTTON_MASK (GDK_BUTTON1_MASK|GDK_BUTTON2_MASK|GDK_BUTTON3_MASK|GDK_BUTTON4_MASK|GDK_BUTTON5_MASK) + +/* remove unused bits, numlock symbol and buttons from keymask */ +#define CLEAN(mask) (mask & (GDK_MODIFIER_MASK) & ~(CLEAN_MOD_NUMLOCK_MASK) & ~(CLEAN_MOD_BUTTON_MASK)) /* callbacks here */ static void inputbox_activate_cb(GtkEntry *entry, gpointer user_data); -- 1.7.3.2 From niemand.is.no.one at gmail.com Mon Nov 15 15:48:10 2010 From: niemand.is.no.one at gmail.com (niemand) Date: Mon, 15 Nov 2010 07:48:10 -0800 (PST) Subject: [Vimprobable-users] How to add new cases for keybinding? Message-ID: Hi, I've gone through vimprobablerc, and while it looks easy enough to set and map the options and functions defined respectively under "Command Mappings" and "Settings" in config.h, how would I go about setting or mapping something that's not defined there? After going through the source code, it doesn't look like there is an easy answer to this... In case there is, I wanted to keep the question general in case anyone else who's kind of new to all of this wants to map or set something not already defined in config.h. What I'm specifically trying to do is map Ctrl-v to toggling caret mode on and off. In this particular case, I'm guessing that I need to edit the "ModeSendKey" case under "webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event)" and "set(const Arg *arg)" in main.c, and then the ModeSendKey line in keymap.h. I could probably figure out on my own how to do this, so if Hannes or Thomas or someone else who actually knows what's up can simply confirm that this would be the way to accomplish what I'm trying to do here, then I'll try my best to do so--teach a girl to fish and all of that! Out of curiosity, what does ModeSendKey currently do? All that happens for me is that "-- PASS TROUGH (next) --" shows up on the input line and the next key is pretty much ignored (e.g. if I press "j" I don't scroll down). Thanks! From hannes at yllr.net Mon Nov 15 15:57:48 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Mon, 15 Nov 2010 16:57:48 +0100 Subject: [Vimprobable-users] How to add new cases for keybinding? In-Reply-To: References: Message-ID: <20101115155746.GA18138@laptop2.lan.localhost> Hi! On Mon, Nov 15, 2010 at 07:48:10AM -0800, niemand wrote: > What I'm specifically trying to do is map Ctrl-v to toggling caret > mode on and off. That will be possible once I get around to implementing keybindings for command lines. Currently, what you could do is define an action for it in config.h, commands[]. Untested: { "careton", process_set_line, {"caret=true"} }, Then, define a mapping for "careton" the usual way. Again, I'm hoping to make this process easier at some point, e.g. :map :set caret=true would be enough then. But don't hold your breath > Out of curiosity, what does ModeSendKey currently do? All that > happens for me is that "-- PASS TROUGH (next) --" shows up on the > input line and the next key is pretty much ignored (e.g. if I press > "j" I don't scroll down). It is meant as "temporary PASSTHROUGH mode". Activate some text input field on a website, press Ctrl-v and then "j" - the "j" should appear in the field. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From niemand.is.no.one at gmail.com Tue Nov 16 18:44:54 2010 From: niemand.is.no.one at gmail.com (niemand) Date: Tue, 16 Nov 2010 10:44:54 -0800 (PST) Subject: [Vimprobable-users] How to add new cases for keybinding? In-Reply-To: <20101115155746.GA18138@laptop2.lan.localhost> References: <20101115155746.GA18138@laptop2.lan.localhost> Message-ID: On Mon, 15 Nov 2010, Hannes Sch?ller wrote: > Hi! > > On Mon, Nov 15, 2010 at 07:48:10AM -0800, niemand wrote: >> What I'm specifically trying to do is map Ctrl-v to toggling caret >> mode on and off. > > That will be possible once I get around to implementing keybindings for > command lines. Currently, what you could do is define an action for it > in config.h, commands[]. Untested: > > { "careton", process_set_line, {"caret=true"} }, > > Then, define a mapping for "careton" the usual way. I tested this out, but unfortunately it didn't work for me... I also tried messing around with main.c & keymap.h (per my half-baked idea in the first email), but I couldn't wrap my mind around gdkkeysyms.h & Xlib.h (I assumed that's where the caret comes from) so I gave up. > > Again, I'm hoping to make this process easier at some point, e.g. > > :map :set caret=true > > would be enough then. But don't hold your breath Keybindings on the command line would be pretty awesome. One of my favorite things about vim is the degree of customization you can get, so I'm glad something similar is in the works for vimprobable--but I won't hold my breath! > >> Out of curiosity, what does ModeSendKey currently do? All that >> happens for me is that "-- PASS TROUGH (next) --" shows up on the >> input line and the next key is pretty much ignored (e.g. if I press >> "j" I don't scroll down). > > It is meant as "temporary PASSTHROUGH mode". Activate some text input > field on a website, press Ctrl-v and then "j" - the "j" should appear in > the field. > > Hannes > From thomas at xteddy.org Tue Nov 16 18:51:46 2010 From: thomas at xteddy.org (Thomas Adam) Date: Tue, 16 Nov 2010 18:51:46 +0000 Subject: [Vimprobable-users] How to add new cases for keybinding? In-Reply-To: References: <20101115155746.GA18138@laptop2.lan.localhost> Message-ID: <20101116185144.GA3334@shuttle.home> On Tue, Nov 16, 2010 at 10:44:54AM -0800, niemand wrote: > On Mon, 15 Nov 2010, Hannes Sch?ller wrote: > > >Hi! > > > >On Mon, Nov 15, 2010 at 07:48:10AM -0800, niemand wrote: > >>What I'm specifically trying to do is map Ctrl-v to toggling caret > >>mode on and off. > > > >That will be possible once I get around to implementing keybindings for > >command lines. Currently, what you could do is define an action for it > >in config.h, commands[]. Untested: > > > >{ "careton", process_set_line, {"caret=true"} }, > > > >Then, define a mapping for "careton" the usual way. > > I tested this out, but unfortunately it didn't work for me... Works just fine for me. What is it you're trying to do? > I also tried messing around with main.c & keymap.h (per my > half-baked idea in the first email), but I couldn't wrap my mind > around gdkkeysyms.h & Xlib.h (I assumed that's where the caret comes > from) so I gave up. No, nothing to do with X11 or GDK -- this is wholly webkit. [..] -- 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 mtreibton at googlemail.com Tue Nov 16 20:09:06 2010 From: mtreibton at googlemail.com (Michael Treibton) Date: Tue, 16 Nov 2010 20:09:06 +0000 Subject: [Vimprobable-users] Developer Interview? Message-ID: Hi, I think it would be really cool to interview the developer(s) of Vimprobable -- I'd be willing to do that so I can then write it up for publication -- perhaps on linux gazette? Is that something anyone here would be interested in? Such as the history of the project, the users, the people behind it, etc., etc. Thanks! Michael From hannes at yllr.net Tue Nov 16 21:13:11 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Tue, 16 Nov 2010 22:13:11 +0100 Subject: [Vimprobable-users] Developer Interview? In-Reply-To: References: Message-ID: <20101116211310.GC1934@laptop2.lan.localhost> Hello Michael! On Tue, Nov 16, 2010 at 08:09:06PM +0000, Michael Treibton wrote: > I think it would be really cool to interview the developer(s) of > Vimprobable -- I'd be willing to do that so I can then write it up for > publication -- perhaps on linux gazette? > > Is that something anyone here would be interested in? Such as the > history of the project, the users, the people behind it, etc., etc. I haven't really talked to the other developers yet, but I'd just like to shoot a general 'yes' in your direction. It would be great, of course, if there was room for everybody's answers (provided the others are willing and interested to do so). I'd say just send your questions to me (and, ideally, some general remarks about how much material you want, who's the target audience etc.) and we'll work out the rest among the developers. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From mtreibton at googlemail.com Tue Nov 16 21:37:19 2010 From: mtreibton at googlemail.com (Michael Treibton) Date: Tue, 16 Nov 2010 21:37:19 +0000 Subject: [Vimprobable-users] Developer Interview? In-Reply-To: <20101116211310.GC1934@laptop2.lan.localhost> References: <20101116211310.GC1934@laptop2.lan.localhost> Message-ID: hi, 2010/11/16 Hannes Sch?ller : > I haven't really talked to the other developers yet, but I'd just like > to shoot a general 'yes' in your direction. It would be great, of > course, if there was room for everybody's answers (provided the others > are willing and interested to do so). I'd say just send your questions > to me (and, ideally, some general remarks about how much material you > want, who's the target audience etc.) and we'll work out the rest among > the developers. i was thinking of the some of something like this: * Introduce yourselves -- how long have you been using/developing Vimprobable, and what attracted you to it? * How did Vimprobable start -- and what was the main motivation behind writing it? * There's been something of an explosion regarding minimal web-browser, and basing them on editors as inspiration. Do you think Vi(m) lends itself well to this in web-browsing, and why? * Most people will have heard of Vimperator -- what limitations does this have which make it undesirable for people who have or are thinking of swithing to Vimprobable. Is this a worthy consideration? * Does webkit -- the rendering engine used as a basis for Vimprobable -- make it easier or harder to write modal web browsers? Are there any disadvantages to using Gecko, from Firefox? * What major features or roadmap does Vimprobable have ahead? Are there any limitations in any of the libraries Vimprobable might use which will make these tasks easier or harder? * At the moment there seems to be two Vimprobable versions. What process model is used to decide if a feature or bug-fix affects both. Does this project need both versions, and as a user, which one is best-suited? * Given the current fad of many similar projects to Vimprobable, what makes this one more "attractive" than the other ones, in your opinion? what do you think? with room for other questions if you like. :) Michael From hannes at yllr.net Fri Nov 19 16:37:26 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Fri, 19 Nov 2010 17:37:26 +0100 Subject: [Vimprobable-users] Developer Interview? In-Reply-To: References: <20101116211310.GC1934@laptop2.lan.localhost> Message-ID: <20101119173726.76254f74@workstation> Hi, a little patience, please. We're trying to compile out answers over the weekend. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From thomas at xteddy.org Fri Nov 19 23:26:34 2010 From: thomas at xteddy.org (Thomas Adam) Date: Fri, 19 Nov 2010 23:26:34 +0000 Subject: [Vimprobable-users] [PATCH 1/1] Fix "map" processing in config files. Message-ID: <20101119232631.GA8529@shuttle.home> Trying to calculate the size of an extern array at runtime is fatal -- it's also going to either evaluate to zero (if passed by pointer) or fail at compilation, because sizeof is compile-time only. Therefore, give the commands[] array a pre-calculated size -- which can then be used properly when trying to set any "map" lines encountered in Vimprobable's config file. --- I am not sure how this ever worked in the past, BTW. :) I'm guessing it used to before we chopped things around forcing extern statements? :) config.h | 2 +- utilities.c | 2 +- vimprobable.h | 3 +++ 3 files changed, 5 insertions(+), 2 deletions(-) diff --git a/config.h b/config.h index 0364d65..bc8d533 100644 --- a/config.h +++ b/config.h @@ -83,7 +83,7 @@ static Searchengine searchengines[] = { static Searchengine *defsearch = &searchengines[0]; /* command mapping */ -Command commands[] = { +Command commands[COMMANDSIZE] = { /* command, function, argument */ { "ba", navigate, {NavigationBack} }, { "back", navigate, {NavigationBack} }, diff --git a/utilities.c b/utilities.c index 0707fbb..3001d5a 100644 --- a/utilities.c +++ b/utilities.c @@ -13,7 +13,7 @@ #include "utilities.h" extern char commandhistory[COMMANDHISTSIZE][255]; -extern Command *commands; +extern Command commands[COMMANDSIZE]; extern int lastcommand, maxcommands, commandpointer; extern KeyList *keylistroot; extern Key keys[]; diff --git a/vimprobable.h b/vimprobable.h index af81d7c..72fe819 100644 --- a/vimprobable.h +++ b/vimprobable.h @@ -168,5 +168,8 @@ typedef struct { #define HISTORY_STORAGE_FILENAME "%s/.config/vimprobable/history", getenv("HOME") #define CLOSED_URL_FILENAME "%s/.config/vimprobable/closed", getenv("HOME") +/* Command size */ +#define COMMANDSIZE 1024 + /* completion list size */ #define MAX_LIST_SIZE 40 -- 1.7.1 From niemand.is.no.one at gmail.com Sat Nov 20 00:55:51 2010 From: niemand.is.no.one at gmail.com (niemand) Date: Fri, 19 Nov 2010 16:55:51 -0800 (PST) Subject: [Vimprobable-users] How to add new cases for keybinding? In-Reply-To: <20101116185144.GA3334@shuttle.home> References: <20101115155746.GA18138@laptop2.lan.localhost> <20101116185144.GA3334@shuttle.home> Message-ID: >>> On Mon, Nov 15, 2010 at 07:48:10AM -0800, niemand wrote: >>>> What I'm specifically trying to do is map Ctrl-v to toggling caret >>>> mode on and off. >>> >>> That will be possible once I get around to implementing keybindings for >>> command lines. Currently, what you could do is define an action for it >>> in config.h, commands[]. Untested: >>> >>> { "careton", process_set_line, {"caret=true"} }, >>> >>> Then, define a mapping for "careton" the usual way. >> >> I tested this out, but unfortunately it didn't work for me... > It turned out that one reason why Hannes' solution wasn't working for me was because I couldn't map keys. Thomas patch earlier totally fixed that! However, Hannes' solution is still not working for me... I've tried adding other mapping definitions (e.g. { "dumbuseragent", process_set_line, {"useragent=blahblahblah"} }, ), but they don't work either. Any ideas? Thanks! From thomas at xteddy.org Sat Nov 20 01:07:32 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sat, 20 Nov 2010 01:07:32 +0000 Subject: [Vimprobable-users] How to add new cases for keybinding? In-Reply-To: References: <20101115155746.GA18138@laptop2.lan.localhost> <20101116185144.GA3334@shuttle.home> Message-ID: <20101120010731.GA3344@shuttle.home> On Fri, Nov 19, 2010 at 04:55:51PM -0800, niemand wrote: > However, Hannes' solution is still not working for me... I've tried > adding other mapping definitions (e.g. { "dumbuseragent", > process_set_line, {"useragent=blahblahblah"} }, ), but they don't > work either. It won't ever work because of this: typedef struct { char *cmd; gboolean(*func) (const Arg * arg); const Arg arg; } Command; So, adding anything to the Command command[] in config.h assumes the function you're calling (in this case process_set_line() itself excepts an Arg* -- but it doesn't. The declaration for process_set_line() accepts a char*. Oh well. -- 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 Nov 20 02:28:45 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sat, 20 Nov 2010 02:28:45 +0000 Subject: [Vimprobable-users] [PATCH 1/1] Fixup function declarations. Message-ID: <20101120022842.GA13683@shuttle.home> Fix sloppy function declarations by declaring (void) where applicable. --- main.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/main.c b/main.c index 74a5b57..1f28e24 100644 --- a/main.c +++ b/main.c @@ -2257,7 +2257,7 @@ update_cookie_jar(SoupCookie *new) } void -save_all_cookies() +save_all_cookies(void) { GSList *session_cookie_list = soup_cookie_jar_all_cookies(session_cookie_jar); @@ -2273,7 +2273,7 @@ save_all_cookies() } void -load_all_cookies() +load_all_cookies(void) { file_cookie_jar = soup_cookie_jar_text_new(cookie_store, COOKIES_STORAGE_READONLY); -- 1.7.1 From thomas at xteddy.org Sat Nov 20 03:09:26 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sat, 20 Nov 2010 03:09:26 +0000 Subject: [Vimprobable-users] [PATCH 0/2] Add V_DEBUG make target Message-ID: <20101120030922.GA15000@shuttle.home> Introduce V_DEBUG in the Makefile to enable not only sanity checking, but to compile Vimprobable with debug symbols, useful when wanting to analyse reproducable corefiles, patching, etc. Off by default, of course. Thomas Adam (2): Add V_DEBUG target. Update PATCHES to reflect V_DEBUG make target. Makefile | 9 +++++++++ PATCHES | 12 ++++++++++++ 2 files changed, 21 insertions(+), 0 deletions(-) From thomas at xteddy.org Sat Nov 20 03:09:49 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sat, 20 Nov 2010 03:09:49 +0000 Subject: [Vimprobable-users] [PATCH 1/2] Add V_DEBUG target. Message-ID: <20101120030946.GA15036@shuttle.home> Useful for debugging and submitting patches. --- Makefile | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index 12b29ed..3502a98 100644 --- a/Makefile +++ b/Makefile @@ -11,9 +11,18 @@ CLEAN = $(TARGET) $(OBJ) $(DEPS) javascript.h # Files to install by install target or remove by uninstall target INSTALL = $(BINDIR)/$(TARGET) $(addprefix $(MANDIR)/man1/,$(MAN)) +# DEBUG build? Off by default +V_DEBUG = 0 + CFLAGS += `pkg-config --cflags $(LIBS)` LDFLAGS += `pkg-config --libs $(LIBS)` +# TA: This is a pretty stringent list of warnings to bail on! +ifeq ($(V_DEBUG),1) +CFLAGS += -g -ggdb -ansi -Wstrict-prototypes +CFLAGS += -Wno-long-long -Wall -Wmissing-declarations +endif + PREFIX ?= /usr/local BINDIR ?= $(PREFIX)/bin MANDIR ?= $(PREFIX)/share/man -- 1.7.1 From thomas at xteddy.org Sat Nov 20 03:10:15 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sat, 20 Nov 2010 03:10:15 +0000 Subject: [Vimprobable-users] [PATCH 2/2] Update PATCHES to reflect V_DEBUG make target. Message-ID: <20101120031013.GA15048@shuttle.home> Mention how V_DEBUG is meant to help with debug builds/sending patches. --- PATCHES | 12 ++++++++++++ 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/PATCHES b/PATCHES index bb2b305..89401a0 100644 --- a/PATCHES +++ b/PATCHES @@ -101,6 +101,18 @@ $ git checkout my-new-feature rebasing against origin/vimprobable2 -- although that's not being mentioned here in the general case, but would equally be acceptable.) +Compiling/Testing patches +========================= + +Before you send patches to the mailing list, please ensure that you compile +Vimprobable using the V_DEBUG target, as in the following: + +$ make clean && make V_DEBUG=1 + +This not only compiles with "-g -ggdb" (for debug symbols), but also runs +some sanity check to ensure you've not missed anything. If you have, fix up +any warnings or errors, and repeat the above command until it's clean. + Generating patches to send to the mailing list ============================================== -- 1.7.1 From hannes at yllr.net Sat Nov 20 08:06:26 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Sat, 20 Nov 2010 09:06:26 +0100 Subject: [Vimprobable-users] How to add new cases for keybinding? In-Reply-To: <20101120010731.GA3344@shuttle.home> References: <20101115155746.GA18138@laptop2.lan.localhost> <20101116185144.GA3334@shuttle.home> <20101120010731.GA3344@shuttle.home> Message-ID: <20101120080624.GA2181@laptop2.lan.localhost> On Sat, Nov 20, 2010 at 01:07:32AM +0000, Thomas Adam wrote: > On Fri, Nov 19, 2010 at 04:55:51PM -0800, niemand wrote: > > However, Hannes' solution is still not working for me... I've tried > > adding other mapping definitions (e.g. { "dumbuseragent", > > process_set_line, {"useragent=blahblahblah"} }, ), but they don't > > work either. > > It won't ever work because of this: > > typedef struct { > char *cmd; > gboolean(*func) (const Arg * arg); > const Arg arg; > } Command; > > So, adding anything to the Command command[] in config.h assumes the > function you're calling (in this case process_set_line() itself excepts an > Arg* -- but it doesn't. The declaration for process_set_line() accepts a > char*. > > Oh well. Hence "untested" :) Your best bet is to write a simple wrapper function which accepts an Arg and passes the string argument on. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From hannes at yllr.net Sat Nov 20 12:03:17 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Sat, 20 Nov 2010 13:03:17 +0100 Subject: [Vimprobable-users] [PATCH 1/1] Fix "map" processing in config files. In-Reply-To: <20101119232631.GA8529@shuttle.home> References: <20101119232631.GA8529@shuttle.home> Message-ID: <20101120120316.GA1946@laptop2.lan.localhost> Merged. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From hannes at yllr.net Sat Nov 20 12:12:01 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Sat, 20 Nov 2010 13:12:01 +0100 Subject: [Vimprobable-users] [PATCH 1/1] Fix "map" processing in config files. In-Reply-To: <20101120120316.GA1946@laptop2.lan.localhost> References: <20101119232631.GA8529@shuttle.home> <20101120120316.GA1946@laptop2.lan.localhost> Message-ID: <20101120121201.GB1946@laptop2.lan.localhost> On Sat, Nov 20, 2010 at 01:03:17PM +0100, Hannes Sch?ller wrote: > Merged. I should add: merged, but this causes several crashes - whenever LENGTH(commands) is called. Have to investigate. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From hannes at yllr.net Sat Nov 20 12:28:28 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Sat, 20 Nov 2010 13:28:28 +0100 Subject: [Vimprobable-users] [PATCH 1/1] Fix "map" processing in config files. In-Reply-To: <20101120121201.GB1946@laptop2.lan.localhost> References: <20101119232631.GA8529@shuttle.home> <20101120120316.GA1946@laptop2.lan.localhost> <20101120121201.GB1946@laptop2.lan.localhost> Message-ID: <20101120122826.GA8915@laptop2.lan.localhost> On Sat, Nov 20, 2010 at 01:12:01PM +0100, Hannes Sch?ller wrote: > On Sat, Nov 20, 2010 at 01:03:17PM +0100, Hannes Sch?ller wrote: > > Merged. > > I should add: merged, but this causes several crashes - whenever > LENGTH(commands) is called. Have to investigate. Using Thomas' patch means that we can never use LENGTH(commands) as a loop condition exclusively. A simple way to work around this is this, for example: for (i = 0; i < LENGTH(commands); i++) { if (commands[i].cmd == NULL) break; /* actual code following... */ } Is this alright with everyone? Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From hannes at yllr.net Sat Nov 20 12:30:50 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Sat, 20 Nov 2010 13:30:50 +0100 Subject: [Vimprobable-users] Mapping keys to command lines Message-ID: <20101120123049.GB8915@laptop2.lan.localhost> Hello everyone, here is a patch to allow mappings like this: :map =[command line] So, for example: :map =:set images=false Feedback appreciated! Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: cmd_mappings.patch Type: text/x-diff Size: 5136 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From thomas at xteddy.org Sat Nov 20 13:55:03 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sat, 20 Nov 2010 13:55:03 +0000 Subject: [Vimprobable-users] [PATCH 1/1] Fix "map" processing in config files. In-Reply-To: <20101120122826.GA8915@laptop2.lan.localhost> References: <20101119232631.GA8529@shuttle.home> <20101120120316.GA1946@laptop2.lan.localhost> <20101120121201.GB1946@laptop2.lan.localhost> <20101120122826.GA8915@laptop2.lan.localhost> Message-ID: <20101120135411.GA3413@shuttle.home> On Sat, Nov 20, 2010 at 01:28:28PM +0100, Hannes Sch?ller wrote: > On Sat, Nov 20, 2010 at 01:12:01PM +0100, Hannes Sch?ller wrote: > > On Sat, Nov 20, 2010 at 01:03:17PM +0100, Hannes Sch?ller wrote: > > > Merged. > > > > I should add: merged, but this causes several crashes - whenever > > LENGTH(commands) is called. Have to investigate. Interesting -- didn't crash at all for me. > Using Thomas' patch means that we can never use LENGTH(commands) as a > loop condition exclusively. A simple way to work around this is this, > for example: > > for (i = 0; i < LENGTH(commands); i++) { > if (commands[i].cmd == NULL) > break; > /* actual code following... */ > } > > Is this alright with everyone? You could put that sort of thing in a macro if you wanted, but otherwise it's fine. -- 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 Nov 20 14:04:22 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sat, 20 Nov 2010 14:04:22 +0000 Subject: [Vimprobable-users] Mapping keys to command lines In-Reply-To: <20101120123049.GB8915@laptop2.lan.localhost> References: <20101120123049.GB8915@laptop2.lan.localhost> Message-ID: <20101120140420.GB3413@shuttle.home> Hello -- On Sat, Nov 20, 2010 at 01:30:50PM +0100, Hannes Sch?ller wrote: > if (text[0] == ':') { > for (i = 0; i < LENGTH(commands); i++) { > + if (commands[i].cmd == NULL) > + break; As mentioned -- perhaps provide a macro for this? > len = strlen(commands[i].cmd); > if (length >= len && !strncmp(&text[1], commands[i].cmd, len) && (text[len + 1] == ' ' || !text[len + 1])) { > found = TRUE; > @@ -798,6 +800,8 @@ complete(const Arg *arg) { > /* command completion */ > listlen = LENGTH(commands); > for (i = 0; i < listlen; i++) { > + if (commands[i].cmd == NULL) > + break; Macro? > cmdlen = strlen(commands[i].cmd); > if (!highlight || (n < MAX_LIST_SIZE && len - 1 <= cmdlen && !strncmp(&str[1], commands[i].cmd, len - 1))) { > p = s = malloc(sizeof(char*) * (highlight ? sizeof(COMPLETION_TAG_OPEN) + sizeof(COMPLETION_TAG_CLOSE) - 1 : 1) + cmdlen); > diff --git a/utilities.c b/utilities.c > index 3001d5a..1ec8d3b 100644 > --- a/utilities.c > +++ b/utilities.c > @@ -214,8 +214,19 @@ parse_colour(char *color) { > } > > gboolean > -changemapping(Key * search_key, int maprecord) { > +process_line_arg(const Arg *arg) { > + return process_line(arg->s); > +} > + > +gboolean > +changemapping(Key *search_key, int maprecord, char *cmd) { > KeyList *current, *newkey; > + Arg a = { .s = cmd }; > + > + /* sanity check */ > + if (maprecord < 0 && cmd == NULL) { > + return FALSE; > + } Do you guarantee a relationship here between maprecord being less than zero implies *cmd is NULL? Do you not mean? if (maprecord < 0 || cmd == NULL) (The belt and braces approach used elsewhere ought to always guarantee cmd != NULL, but it's still a good check to have here, I agree.) > gboolean > @@ -339,23 +355,30 @@ process_map_line(char *line) { > int listlen, i; > char *c; > my_pair.line = line; > - c = search_word (0); > + c = search_word(0); It would be nice to see an enum or #define for these options to search_word(). > - if (!strlen (my_pair.what)) > + if (!strlen(my_pair.what)) > return FALSE; > - while (isspace (*c) && *c) > + while (isspace(*c) && *c) > c++; > > if (*c == ':' || *c == '=') > c++; > my_pair.line = c; > - c = search_word (1); > - if (!strlen (my_pair.value)) > + c = search_word(1); Ditto. I've not checked, but "c" here, doesn't ever need free()ing after calling search_word() does it? ISTR it's naughtily never used for anything other than to affect the state of some global my_pair. :/ > + if (!strlen(my_pair.value)) > return FALSE; > listlen = LENGTH(commands); > for (i = 0; i < listlen; i++) { > + /* commands is fixed size */ > + if (commands[i].cmd == NULL) > + break; > if (strlen(commands[i].cmd) == strlen(my_pair.value) && strncmp(commands[i].cmd, my_pair.value, strlen(my_pair.value)) == 0) > - return process_mapping(my_pair.what, i); > + return process_mapping(my_pair.what, i, NULL); > + } > + /* if this is reached, the mapping is not for one of the internal signals - test for command line structure */ > + if (strncmp(my_pair.value, ":", 1) == 0) { > + return process_mapping(my_pair.what, -1, (my_pair.value + 1)); Perhaps a comment for this line? Otherwise looks fine. -- 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 Nov 20 22:01:16 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Sat, 20 Nov 2010 23:01:16 +0100 Subject: [Vimprobable-users] Mapping keys to command lines In-Reply-To: <20101120140420.GB3413@shuttle.home> References: <20101120123049.GB8915@laptop2.lan.localhost> <20101120140420.GB3413@shuttle.home> Message-ID: <20101120220116.GA13721@laptop2.lan.localhost> Hi! On Sat, Nov 20, 2010 at 02:04:22PM +0000, Thomas Adam wrote: > On Sat, Nov 20, 2010 at 01:30:50PM +0100, Hannes Sch?ller wrote: > > diff --git a/utilities.c b/utilities.c > > index 3001d5a..1ec8d3b 100644 > > --- a/utilities.c > > +++ b/utilities.c > > @@ -214,8 +214,19 @@ parse_colour(char *color) { > > } > > > > gboolean > > -changemapping(Key * search_key, int maprecord) { > > +process_line_arg(const Arg *arg) { > > + return process_line(arg->s); > > +} > > + > > +gboolean > > +changemapping(Key *search_key, int maprecord, char *cmd) { > > KeyList *current, *newkey; > > + Arg a = { .s = cmd }; > > + > > + /* sanity check */ > > + if (maprecord < 0 && cmd == NULL) { > > + return FALSE; > > + } > > Do you guarantee a relationship here between maprecord being less than zero > implies *cmd is NULL? Do you not mean? > > if (maprecord < 0 || cmd == NULL) > > (The belt and braces approach used elsewhere ought to always guarantee cmd > != NULL, but it's still a good check to have here, I agree.) No, the line is correct. maprecord being >= 0 is combined with cmd being NULL. This means that this is a 'classic' keybinding (binding to a defined internal signal). maprecord < 0 is always combined with cmd != NULL - then, it's a command line binding (the new stuff). If NEITHER approach is set, something is wrong, hence returning FALSE before anything is even attempted. See lines 377 and 381 in utilities.c (where this function is called). > > gboolean > > @@ -339,23 +355,30 @@ process_map_line(char *line) { > > int listlen, i; > > char *c; > > my_pair.line = line; > > - c = search_word (0); > > + c = search_word(0); > > It would be nice to see an enum or #define for these options to > search_word(). > > > - if (!strlen (my_pair.what)) > > + if (!strlen(my_pair.what)) > > return FALSE; > > - while (isspace (*c) && *c) > > + while (isspace(*c) && *c) > > c++; > > > > if (*c == ':' || *c == '=') > > c++; > > my_pair.line = c; > > - c = search_word (1); > > - if (!strlen (my_pair.value)) > > + c = search_word(1); > > Ditto. I haven't really touched these. What you see here is only whitespace fixes (I know, bad style to combine these with a change in functionality). > > + if (!strlen(my_pair.value)) > > return FALSE; > > listlen = LENGTH(commands); > > for (i = 0; i < listlen; i++) { > > + /* commands is fixed size */ > > + if (commands[i].cmd == NULL) > > + break; > > if (strlen(commands[i].cmd) == strlen(my_pair.value) && strncmp(commands[i].cmd, my_pair.value, strlen(my_pair.value)) == 0) > > - return process_mapping(my_pair.what, i); > > + return process_mapping(my_pair.what, i, NULL); > > + } > > + /* if this is reached, the mapping is not for one of the internal signals - test for command line structure */ > > + if (strncmp(my_pair.value, ":", 1) == 0) { > > > + return process_mapping(my_pair.what, -1, (my_pair.value + 1)); > Perhaps a comment for this line? Agreed, will add one. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From thomas at xteddy.org Sat Nov 20 22:13:41 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sat, 20 Nov 2010 22:13:41 +0000 Subject: [Vimprobable-users] Mapping keys to command lines In-Reply-To: <20101120220116.GA13721@laptop2.lan.localhost> References: <20101120123049.GB8915@laptop2.lan.localhost> <20101120140420.GB3413@shuttle.home> <20101120220116.GA13721@laptop2.lan.localhost> Message-ID: <20101120221340.GA3182@shuttle.home> On Sat, Nov 20, 2010 at 11:01:16PM +0100, Hannes Sch?ller wrote: > No, the line is correct. maprecord being >= 0 is combined with cmd being OK. Needs a comment then as it's not obvious. (The relationship implied there is knee-deep in some other function, so having the logic here is out of context to understanding why --- could be mitigated through other means, but for now a comment will suffice, I think.) > I haven't really touched these. What you see here is only whitespace > fixes (I know, bad style to combine these with a change in > functionality). Sure -- but you have touched it nevertheless -- and if you're going to fix whitespace, you might as well go the whole hog [1] and realise it probably needs a #define or an enum. :) -- Thomas Adam [1] English has some odd expressions. -- "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 Nov 20 22:16:28 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Sat, 20 Nov 2010 23:16:28 +0100 Subject: [Vimprobable-users] Mapping keys to command lines In-Reply-To: <20101120221340.GA3182@shuttle.home> References: <20101120123049.GB8915@laptop2.lan.localhost> <20101120140420.GB3413@shuttle.home> <20101120220116.GA13721@laptop2.lan.localhost> <20101120221340.GA3182@shuttle.home> Message-ID: <20101120221628.GB13721@laptop2.lan.localhost> On Sat, Nov 20, 2010 at 10:13:41PM +0000, Thomas Adam wrote: > On Sat, Nov 20, 2010 at 11:01:16PM +0100, Hannes Sch?ller wrote: > > No, the line is correct. maprecord being >= 0 is combined with cmd being > > OK. Needs a comment then as it's not obvious. (The relationship implied > there is knee-deep in some other function, so having the logic here is out > of context to understanding why --- could be mitigated through other means, > but for now a comment will suffice, I think.) Definitely agreed that it's not obvious. I'll add extensive comments both to the calling side and into the function itself to document the logic. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From mtreibton at googlemail.com Sun Nov 21 20:33:52 2010 From: mtreibton at googlemail.com (Michael Treibton) Date: Sun, 21 Nov 2010 20:33:52 +0000 Subject: [Vimprobable-users] Developer Interview? In-Reply-To: <20101119173726.76254f74@workstation> References: <20101116211310.GC1934@laptop2.lan.localhost> <20101119173726.76254f74@workstation> Message-ID: 2010/11/19 Hannes Sch?ller : > Hi, > > a little patience, please. We're trying to compile out answers over the > weekend. hi - how's this coming along? :) Michael From niemand.is.no.one at gmail.com Sun Nov 21 22:31:15 2010 From: niemand.is.no.one at gmail.com (niemand) Date: Sun, 21 Nov 2010 14:31:15 -0800 (PST) Subject: [Vimprobable-users] Mapping keys to command lines In-Reply-To: <20101120123049.GB8915@laptop2.lan.localhost> References: <20101120123049.GB8915@laptop2.lan.localhost> Message-ID: On Sat, 20 Nov 2010, Hannes Sch?ller wrote: > Hello everyone, > > here is a patch to allow mappings like this: > > :map =[command line] > > So, for example: > > :map =:set images=false > > Feedback appreciated! > > Hannes > Is it me, or is this only good for one shot? For example, if you map ^v to caret=true, then you can press ^v to go into caret mode, but if you exit caret mode, you can't enable caret browsing with ^v until you map it to caret=true again. Also, I can only map one key at a time to the command line (e.g. I can either map ^v to enable caret browsing or ^x to disable it, but I can't map both so that I can enable caret browsing with ^v and then disable it with ^x, as only the latest mapping will obtain). FYI I did not have the same problem when I mapped s=scrolldown & w=scrollup. From niemand.is.no.one at gmail.com Mon Nov 22 10:48:39 2010 From: niemand.is.no.one at gmail.com (niemand) Date: Mon, 22 Nov 2010 02:48:39 -0800 (PST) Subject: [Vimprobable-users] A general toggling patch Message-ID: I've been trying for some days now to figure out a way to set ^v to toggle in and out of caret mode. I was lucky enough to find a patch by stanio for suckless.org's surf that allows one to set in config.h all sorts of fun webkit related settings not easily keymapped and to toggle them on and off with a single key. I adapted it here to vimprobable (patch included below and is also attached for convenience). In the patch is an example, enable-caret-browsing mapped to ^v, which can be generalized to other keys and webkit settings, though you have to do the editting in keymap.h and recompile vimprobable. I tested it on a fresh copy of vimprobable2 v.0.9.6.3, so it should work. That said, while I am happy that I can finally toggle caret mode and whatever else I want, it would be nice if someone who actually knows how to program could adapt this patch to vimprobable further so that keys can be mapped in vimprobablerc. Enjoy! diff -rup a/keymap.h b/keymap.h --- a/keymap.h 2010-11-13 02:41:19.000000000 -0800 +++ b/keymap.h 2010-11-22 02:15:48.643718228 -0800 @@ -100,10 +100,12 @@ Key keys[] = { { 0, GDK_VoidSymbol, GDK_Escape, set, {ModeNormal} }, { GDK_CONTROL_MASK, 0, GDK_z, set, {ModePassThrough} }, - { GDK_CONTROL_MASK, 0, GDK_v, set, {ModeSendKey} }, + /*{ GDK_CONTROL_MASK, 0, GDK_v, set, {ModeSendKey} },*/ { 0, 0, GDK_f, set, { .i = ModeHints, .s = "current" } }, { GDK_SHIFT_MASK, 0, GDK_F, set, { .i = ModeHints, .s = "new" } }, + { GDK_CONTROL_MASK, 0, GDK_v, toggle, { .s = "enable-caret-browsing" } }, + { 0, GDK_g, GDK_i, focus_input,{} }, { 0, 0, GDK_u, revive, {} }, diff -rup a/main.c b/main.c --- a/main.c 2010-11-13 02:41:19.000000000 -0800 +++ b/main.c 2010-11-22 02:16:25.636721537 -0800 @@ -84,6 +84,7 @@ static gboolean process_set_line(char *l void save_command_history(char *line); void toggle_proxy(gboolean onoff); void toggle_scrollbars(gboolean onoff); +static void toggle(const Arg *arg); gboolean process_keypress(GdkEventKey *event); void fill_suggline(char * suggline, const char * command, const char *fill_with); @@ -1877,6 +1878,17 @@ toggle_scrollbars(gboolean onoff) { } void +toggle(const Arg *arg) { + WebKitWebSettings *settings; + settings = webkit_web_view_get_settings(webview); + char *name = (char *)arg->s; + gboolean value; + + g_object_get(G_OBJECT(settings), name, &value, NULL); + g_object_set(G_OBJECT(settings), name, !value, NULL); +} + +void update_url(const char *uri) { gboolean ssl = g_str_has_prefix(uri, "https://"); GdkColor color; -------------- next part -------------- A non-text attachment was scrubbed... Name: toggle.patch Type: text/x-diff Size: 2034 bytes Desc: URL: From thomas at xteddy.org Mon Nov 22 11:31:05 2010 From: thomas at xteddy.org (Thomas Adam) Date: Mon, 22 Nov 2010 11:31:05 +0000 Subject: [Vimprobable-users] A general toggling patch In-Reply-To: References: Message-ID: <20101122113058.GA4109@abacus.soton.smoothwall.net> On Mon, Nov 22, 2010 at 02:48:39AM -0800, niemand wrote: > - { GDK_CONTROL_MASK, 0, GDK_v, set, > {ModeSendKey} }, > + /*{ GDK_CONTROL_MASK, 0, GDK_v, set, > {ModeSendKey} },*/ We don't comment things out like this. > +static void toggle(const Arg *arg); This name is far too generic. "toggle_webkit_settings" > gboolean process_keypress(GdkEventKey *event); > void fill_suggline(char * suggline, const char * command, const > char *fill_with); > @@ -1877,6 +1878,17 @@ toggle_scrollbars(gboolean onoff) { > } > > void > +toggle(const Arg *arg) { > + WebKitWebSettings *settings; > + settings = webkit_web_view_get_settings(webview); > + char *name = (char *)arg->s; No need to cast here at all. arg->s is not a void*, it's a char*. > + gboolean value; > + > + g_object_get(G_OBJECT(settings), name, &value, NULL); > + g_object_set(G_OBJECT(settings), name, !value, NULL); Intereting, umm, idiom. You cannot use g_object_set() in this way for all options, unfortunately. I think on this occassion, keeping certain options toggleable as separate (like we do scrollbars, proxy, etc.,) is the only safe way to go. -- Thomas Adam From hannes at yllr.net Mon Nov 22 14:37:40 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Mon, 22 Nov 2010 15:37:40 +0100 Subject: [Vimprobable-users] Mapping keys to command lines In-Reply-To: References: <20101120123049.GB8915@laptop2.lan.localhost> Message-ID: <20101122153740.0ae346d1@laptop2.lan.localhost> Hi! niemand wrote: > On Sat, 20 Nov 2010, Hannes Sch?ller wrote: > > Hello everyone, > > > > here is a patch to allow mappings like this: > > > > :map =[command line] > > > > So, for example: > > > > :map =:set images=false > > > > Feedback appreciated! > > Is it me, or is this only good for one shot? For example, if you map > ^v to caret=true, then you can press ^v to go into caret mode, but if > you exit caret mode, you can't enable caret browsing with ^v until > you map it to caret=true again. > > Also, I can only map one key at a time to the command line (e.g. I > can either map ^v to enable caret browsing or ^x to disable it, but I > can't map both so that I can enable caret browsing with ^v and then > disable it with ^x, as only the latest mapping will obtain). > > FYI I did not have the same problem when I mapped s=scrolldown & > w=scrollup. Very well spotted! There were actually two bugs at work here at the same time. Please try this new version (this replaces the old patch, so undo those changes first before applying the new one). Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: cmd_mappings2.patch Type: text/x-patch Size: 7473 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From hannes at yllr.net Mon Nov 22 14:48:55 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Mon, 22 Nov 2010 15:48:55 +0100 Subject: [Vimprobable-users] A general toggling patch In-Reply-To: References: Message-ID: <20101122154855.1d7290b8@laptop2.lan.localhost> Hi! niemand wrote: > I've been trying for some days now to figure out a way to set ^v to > toggle in and out of caret mode. I was lucky enough to find a patch > by stanio for suckless.org's surf that allows one to set in config.h > all sorts of fun webkit related settings not easily keymapped and to > toggle them on and off with a single key. I adapted it here to > vimprobable (patch included below and is also attached for > convenience). As Thomas said, it is unfortunately a little more complicated than this. Just setting the internal webkit option won't necessarily actually enable or disable anything right away. This is just the way webkit works. That is why some options have these special exceptions in the :set code. Generally, I don't like toggles bound to just one key anyway since it's too easy to lose track of the current status of the setting. My personal strategy would be to map KEY to enabling an option, for example, and MOD-KEY to disabling it. So in your case: :map =:set caret=false :map v=:set caret=true Though, of course, the latter is just personal preference. What do you think? Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From niemand.is.no.one at gmail.com Tue Nov 23 03:01:02 2010 From: niemand.is.no.one at gmail.com (niemand) Date: Mon, 22 Nov 2010 19:01:02 -0800 (PST) Subject: [Vimprobable-users] A general toggling patch In-Reply-To: <20101122154855.1d7290b8@laptop2.lan.localhost> References: <20101122154855.1d7290b8@laptop2.lan.localhost> Message-ID: On Mon, 22 Nov 2010, Hannes Sch?ller wrote: > Generally, I don't like toggles bound to just one key anyway since it's > too easy to lose track of the current status of the setting. My > personal strategy would be to map KEY to enabling an option, for > example, and MOD-KEY to disabling it. So in your case: > > :map =:set caret=false > :map v=:set caret=true > > Though, of course, the latter is just personal preference. What do you > think? Doesn't it depend on what setting you're mapping? I know that Thomas Adam's patch for toggling the proxy in suckless' surf changes the color of the loading bar, so it's not like you can forget what state the proxy is in. That said, I would prefer to be able to exit caret mode with ESC rather than a second pressing of v or a first pressing of ^v, but there's no easy way to do that... N.B. Pressing ESC does return me to normal keyboard navigation when caret browsing is enabled, so this isn't much of a complaint :) From hannes at yllr.net Tue Nov 23 14:19:34 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Tue, 23 Nov 2010 15:19:34 +0100 Subject: [Vimprobable-users] A general toggling patch In-Reply-To: References: <20101122154855.1d7290b8@laptop2.lan.localhost> Message-ID: <20101123151934.65babfd1@laptop2.lan.localhost> Hi! niemand wrote: > On Mon, 22 Nov 2010, Hannes Sch?ller wrote: > > Generally, I don't like toggles bound to just one key anyway since > > it's too easy to lose track of the current status of the setting. My > > personal strategy would be to map KEY to enabling an option, for > > example, and MOD-KEY to disabling it. So in your case: > > > > :map =:set caret=false > > :map v=:set caret=true > > > > Though, of course, the latter is just personal preference. What do > > you think? > > Doesn't it depend on what setting you're mapping? Absolutely. Some settings are 'naturally' visible, but I was thinking of the toggles we have in the Vimprobable1 branch, for example. Those are for Javascript and plugins. Neither is really visible. Don't get me wrong, I don't object to the idea to provide users with a generic way of toggling true/false settings. The problem is that your patch introduces a second interface to these webkit settings so we'd have to maintain two pieces of code doing the same thing. Instead of directly setting the webkit option in the toggle function, why not call process_line('set xyz=true') (or false respectively) after checking whether it should be turned on or off by the toggle? Then, we'd have the actual change of the setting only in one place again. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From hannes at yllr.net Sun Nov 28 15:09:02 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sun, 28 Nov 2010 16:09:02 +0100 Subject: [Vimprobable-users] Vimprobable 0.9.20.4 & Vimprobable2 0.9.7.0 released! Message-ID: <20101128160902.3a9d0cc1@workstation> Hi everybody, both branches got a minor bugfix today: newline characters appeared under some circumstances in the completion suggestions. This has been fixed in the new versions. The bigger piece of news is one new feature in the Vimprobable2 branch: Keys can now be mapped to colon commands. For example: :map =:set scripts=false will make Control-s disable Javascript. 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 Nov 28 15:18:06 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sun, 28 Nov 2010 16:18:06 +0100 Subject: [Vimprobable-users] Vimprobable 0.9.20.4 & Vimprobable2 0.9.7.0 released! In-Reply-To: <20101128160902.3a9d0cc1@workstation> References: <20101128160902.3a9d0cc1@workstation> Message-ID: <20101128161806.7ab66b5a@workstation> In case anyone's wondering: I'm aware of a few patches sent to the mailing list still being open. They will be merged in the next release. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: