From hannes at yllr.net Fri Jul 1 09:54:25 2011 From: hannes at yllr.net (Hannes =?ISO-8859-1?Q?Sch=FCller?=) Date: Fri, 1 Jul 2011 16:54:25 +0200 Subject: [Vimprobable-users] [PATCH] Feedback for yank In-Reply-To: <20110622205055.GA18783@linnea> References: <20110622205055.GA18783@linnea> Message-ID: <20110701165425.7eb63667@yllr.net> Hi Daniel! Daniel Carl wrote: > I found it a little confusing to get yank feedback for yanking > current url but not fo yanking marked text like the vimperator plugin > does. I found myself pressing multiple times Y because i got no > feedback about the yanking. Seems to be quite useful - thanks! Hannes From danielcarl at gmx.de Sat Jul 9 09:23:51 2011 From: danielcarl at gmx.de (Daniel Carl) Date: Sat, 9 Jul 2011 16:23:51 +0200 Subject: [Vimprobable-users] [FEATURE] hinting within frames and switching of frames Message-ID: <20110709142351.GA10287@linnea> Hi, i'm sometimes on sites that use frames and iframes and noticed that the hinting and the motion commands don't work properly within the frames. I build a small example that should illustrate the problem. I'm familyr with all the GTK and webkit stuff so, maybe somebody else can fix that. Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannes at yllr.net Sat Jul 9 09:39:58 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 9 Jul 2011 16:39:58 +0200 Subject: [Vimprobable-users] [FEATURE] hinting within frames and switching of frames In-Reply-To: <20110709142351.GA10287@linnea> References: <20110709142351.GA10287@linnea> Message-ID: <20110709163958.3f0f7def@workstation> Hi! Daniel Carl wrote: > i'm sometimes on sites that use frames and iframes and noticed that > the hinting and the motion commands don't work properly within the > frames. I build a small example that should illustrate the problem. > I'm familyr with all the GTK and webkit stuff so, maybe somebody else > can fix that. Yes, this is a known problem. The reason for this is that hinting is done by parsing the DOM tree of a page. On sites with frames, there is more than one tree. So what would have to be done is first resolve the URLs involved, analyse the tree of each HTML page and put hints in (using an offset for the pages after the first one). Then, when a hint number is entered, the link would have to be extracted from the corresponding page this number belongs to. I never really started putting what I just sketched into code. Probably because sites using frames have become so incredibly rare. Patches accepted, of course. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From danielcarl at gmx.de Sat Jul 9 10:08:22 2011 From: danielcarl at gmx.de (Daniel Carl) Date: Sat, 9 Jul 2011 17:08:22 +0200 Subject: [Vimprobable-users] [BUG] in commit 5cfefb1c349a0e6a3e9aaa537cbafbf7ce59faa3 Message-ID: <20110709150822.GA13614@linnea> Hi, sometime when i like to open a page and used :open vim vimprobable crashes if to many suggest are found. This behavior was introduced with commit 5cfefb1c349a0e6a3e9aaa537cbafbf7ce59faa3. Here is the first part of console output after hitting the tab key in the vesion of the commit 5cfefb1: *** stack smashing detected ***: ./vimprobable2 terminated ======= Backtrace: ========= /lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x50)[0xb2cdf0] /lib/i386-linux-gnu/libc.so.6(+0xe5d9a)[0xb2cd9a] ./vimprobable2[0x8053d6d] ./vimprobable2[0x804e04c] ./vimprobable2[0x804cfea] /usr/lib/libgtk-x11-2.0.so.0(+0x135a04)[0x245a04] /usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0x192)[0x935372] /usr/lib/i386-linux-gnu/libgobject-2.0.so.0(+0x1f048)[0x948048] /usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x557)[0x9508d7] /usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x32)[0x950cc2] /usr/lib/libgtk-x11-2.0.so.0(+0x26a836)[0x37a836] /usr/lib/libgtk-x11-2.0.so.0(gtk_window_propagate_key_event+0x10f)[0x392c4f] /usr/lib/libgtk-x11-2.0.so.0(+0x285aec)[0x395aec] /usr/lib/libgtk-x11-2.0.so.0(+0x135a04)[0x245a04] /usr/lib/i386-linux-gnu/libgobject-2.0.so.0(+0xacc7)[0x933cc7] /usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0x192)[0x935372] /usr/lib/i386-linux-gnu/libgobject-2.0.so.0(+0x1ee45)[0x947e45] /usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x557)[0x9508d7] /usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x32)[0x950cc2] /usr/lib/libgtk-x11-2.0.so.0(+0x26a836)[0x37a836] /usr/lib/libgtk-x11-2.0.so.0(gtk_propagate_event+0x1a3)[0x243c63] /usr/lib/libgtk-x11-2.0.so.0(gtk_main_do_event+0x27f)[0x243eef] /usr/lib/libgdk-x11-2.0.so.0(+0x56a0a)[0x5d6a0a] /lib/i386-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x1c8)[0x9b0aa8] /lib/i386-linux-gnu/libglib-2.0.so.0(+0x41270)[0x9b1270] /lib/i386-linux-gnu/libglib-2.0.so.0(g_main_loop_run+0x17b)[0x9b192b] /usr/lib/libgtk-x11-2.0.so.0(gtk_main+0xb9)[0x242c39] ./vimprobable2[0x8052943] /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0xa5de37] ./vimprobable2[0x804b731] Daniel From danielcarl at gmx.de Sat Jul 9 13:47:39 2011 From: danielcarl at gmx.de (Daniel Carl) Date: Sat, 9 Jul 2011 20:47:39 +0200 Subject: [Vimprobable-users] [FEATURE] hinting within frames and switching of frames In-Reply-To: <20110709163958.3f0f7def@workstation> References: <20110709142351.GA10287@linnea> <20110709163958.3f0f7def@workstation> Message-ID: <20110709184739.GA1456@linnea> On Sat, Jul 09, 2011 at 04:39:58PM +0200, Hannes Sch?ller wrote: > Hi! > > Daniel Carl wrote: > > i'm sometimes on sites that use frames and iframes and noticed that > > the hinting and the motion commands don't work properly within the > > frames. I build a small example that should illustrate the problem. > > I'm familyr with all the GTK and webkit stuff so, maybe somebody else > > can fix that. > > Yes, this is a known problem. The reason for this is that hinting is > done by parsing the DOM tree of a page. On sites with frames, there is > more than one tree. So what would have to be done is first resolve the > URLs involved, analyse the tree of each HTML page and put hints in > (using an offset for the pages after the first one). Then, when a hint > number is entered, the link would have to be extracted from the > corresponding page this number belongs to. > > I never really started putting what I just sketched into code. Probably > because sites using frames have become so incredibly rare. Patches > accepted, of course. > > Hannes Hi Hannes, it sound pretty hard to do. But what's with the motioncommands, i think it should be easy to implement, because the cursor already scrolls within a frame if the frame was activated by a mouseklick. Daniel From danielcarl at gmx.de Sat Jul 9 15:07:53 2011 From: danielcarl at gmx.de (Daniel Carl) Date: Sat, 9 Jul 2011 22:07:53 +0200 Subject: [Vimprobable-users] [BUG] in commit 5cfefb1c349a0e6a3e9aaa537cbafbf7ce59faa3 In-Reply-To: <20110709150822.GA13614@linnea> References: <20110709150822.GA13614@linnea> Message-ID: <20110709200753.GA5384@linnea> On Sat, Jul 09, 2011 at 05:08:22PM +0200, Daniel Carl wrote: > Hi, > sometime when i like to open a page and used :open vim vimprobable crashes if > to many suggest are found. This behavior was introduced with commit > 5cfefb1c349a0e6a3e9aaa537cbafbf7ce59faa3. > > Here is the first part of console output after hitting the tab key in the > vesion of the commit 5cfefb1: > > *** stack smashing detected ***: ./vimprobable2 terminated > ======= Backtrace: ========= > /lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x50)[0xb2cdf0] > /lib/i386-linux-gnu/libc.so.6(+0xe5d9a)[0xb2cd9a] > ./vimprobable2[0x8053d6d] > ./vimprobable2[0x804e04c] > ./vimprobable2[0x804cfea] > /usr/lib/libgtk-x11-2.0.so.0(+0x135a04)[0x245a04] > /usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0x192)[0x935372] > /usr/lib/i386-linux-gnu/libgobject-2.0.so.0(+0x1f048)[0x948048] > /usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x557)[0x9508d7] > /usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x32)[0x950cc2] > /usr/lib/libgtk-x11-2.0.so.0(+0x26a836)[0x37a836] > /usr/lib/libgtk-x11-2.0.so.0(gtk_window_propagate_key_event+0x10f)[0x392c4f] > /usr/lib/libgtk-x11-2.0.so.0(+0x285aec)[0x395aec] > /usr/lib/libgtk-x11-2.0.so.0(+0x135a04)[0x245a04] > /usr/lib/i386-linux-gnu/libgobject-2.0.so.0(+0xacc7)[0x933cc7] > /usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0x192)[0x935372] > /usr/lib/i386-linux-gnu/libgobject-2.0.so.0(+0x1ee45)[0x947e45] > /usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x557)[0x9508d7] > /usr/lib/i386-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x32)[0x950cc2] > /usr/lib/libgtk-x11-2.0.so.0(+0x26a836)[0x37a836] > /usr/lib/libgtk-x11-2.0.so.0(gtk_propagate_event+0x1a3)[0x243c63] > /usr/lib/libgtk-x11-2.0.so.0(gtk_main_do_event+0x27f)[0x243eef] > /usr/lib/libgdk-x11-2.0.so.0(+0x56a0a)[0x5d6a0a] > /lib/i386-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x1c8)[0x9b0aa8] > /lib/i386-linux-gnu/libglib-2.0.so.0(+0x41270)[0x9b1270] > /lib/i386-linux-gnu/libglib-2.0.so.0(g_main_loop_run+0x17b)[0x9b192b] > /usr/lib/libgtk-x11-2.0.so.0(gtk_main+0xb9)[0x242c39] > ./vimprobable2[0x8052943] > /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0xa5de37] > ./vimprobable2[0x804b731] > > Daniel I tested a litte around with the entries of the history file and found some lines that couse the crash if they would be matche by the completion. This lines have urls with more than 200 chars like followin example. http://www.handelskraft.de/2011/07/raufeld-media-startet-mit-onlineshop-fuer-artikel-und-redaktionellen-content/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Handelskraft+%28Handelskraft%28 ||| Handelskraft Daniel From evan54 at gmail.com Sat Jul 16 19:23:28 2011 From: evan54 at gmail.com (Anonymous) Date: Sat, 16 Jul 2011 17:23:28 -0700 Subject: [Vimprobable-users] installation issues Message-ID: Hi everyone, trying to install the vimprobable1 version but get the following error.... what i did was sudo make install from the terminal thanks, ERROR MSG: cc -MMD -c `pkg-config --cflags gtk+-2.0 webkit-1.0 libsoup-2.4` main.c -o main.o Package gtk+-2.0 was not found in the pkg-config search path. Perhaps you should add the directory containing `gtk+-2.0.pc' to the PKG_CONFIG_PATH environment variable No package 'gtk+-2.0' found Package webkit-1.0 was not found in the pkg-config search path. Perhaps you should add the directory containing `webkit-1.0.pc' to the PKG_CONFIG_PATH environment variable No package 'webkit-1.0' found Package libsoup-2.4 was not found in the pkg-config search path. Perhaps you should add the directory containing `libsoup-2.4.pc' to the PKG_CONFIG_PATH environment variable No package 'libsoup-2.4' found main.c:16:21: fatal error: gtk/gtk.h: No such file or directory compilation terminated. make: *** [main.o] Error 1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tyler at monkeypox.org Sat Jul 16 19:24:31 2011 From: tyler at monkeypox.org (R. Tyler Croy) Date: Sat, 16 Jul 2011 17:24:31 -0700 Subject: [Vimprobable-users] installation issues In-Reply-To: References: Message-ID: <20110717002431.GB9181@kiwi.local> On Sat, 16 Jul 2011, Anonymous wrote: > Hi everyone, > > trying to install the vimprobable1 version but get the following error.... > > what i did was > > sudo make install You will need the libwebkitgtk-dev and gtk-dev packages installed on your machine (the names might be off depending on your distro - R. Tyler Croy -------------------------------------- Code: http://github.com/rtyler Chatter: http://identi.ca/agentdero http://twitter.com/agentdero -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From evan54 at gmail.com Sat Jul 16 19:35:12 2011 From: evan54 at gmail.com (Anonymous) Date: Sat, 16 Jul 2011 17:35:12 -0700 Subject: [Vimprobable-users] installation issues In-Reply-To: <20110717002431.GB9181@kiwi.local> References: <20110717002431.GB9181@kiwi.local> Message-ID: dude you rock!! sub minute response and it worked like a charm! best On Sat, Jul 16, 2011 at 5:24 PM, R. Tyler Croy wrote: > > On Sat, 16 Jul 2011, Anonymous wrote: > > > Hi everyone, > > > > trying to install the vimprobable1 version but get the following > error.... > > > > what i did was > > > > sudo make install > > You will need the libwebkitgtk-dev and gtk-dev packages installed on your > machine (the names might be off depending on your distro > > - R. Tyler Croy > -------------------------------------- > Code: http://github.com/rtyler > Chatter: http://identi.ca/agentdero > http://twitter.com/agentdero > > _______________________________________________ > 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 evan54 at gmail.com Mon Jul 18 16:26:35 2011 From: evan54 at gmail.com (Anonymous) Date: Mon, 18 Jul 2011 14:26:35 -0700 Subject: [Vimprobable-users] cookies - not enabled Message-ID: hi all, so I got a message that the browser I use doesn't support cookies any idea why how I fix this? It was when I tried to log in to www.ieee-pvsc.org. best, eVan here is the complete message: We have detected that your internet browser does not currently have "cookies" enabled. This website requires the use of cookies so that we can keep track of each users's current page. Please enable cookies and then click here to begin again. *How To Enable Cookies* - Mozilla Firefox (1.0 final release and earlier) ? Go to the "Tools" menu. ? Select "Options". ? Select the "Privacy" icon in the left panel. ? Check the box corresponding to "Allow sites to set cookies". ? Click "OK" to save changes. Netscape 7.1/Mozilla 5.0 ? Select "Preferences" from the Edit menu. ? Click on the arrow next to "Privacy & Security" in the scrolling window to expand. ? Under "Privacy & Security", select "Cookies." ? Select "Enable all cookies". ? Click "OK". Microsoft Internet Explorer 6.0+ ? Select "Internet Options" from the Tools menu. ? Click on the "Privacy" tab. ? Click the "Default" button (or manually slide the bar down to "Medium") under "Settings". ? Click "OK". Microsoft Internet Explorer 5.x ? Select "Internet Options" from the Tools menu. ? Click on the "Security" tab. ? Click the "Custom Level" button. ? Scroll down to the "Cookies" section. ? To enable: ? Set "Allow cookies that are stored on your computer" to "Enable". ? Set "Allow per-session cookies" to "Enable". ? Click "OK". Microsoft Internet Explorer 4.x ? Select "Internet Options" from the View menu. ? Click on the "Advanced" tab. ? Scroll down to find "Cookies" within the "Security" section. ? To enable: ? Select "Always accept cookies". ? Click "OK". Netscape Communicator 4.x ? Select "Preferences" from the Edit menu. ? Find the "Cookies" section in the "Advanced" category. ? To enable: ? Select "Accept all cookies" (or "Enable all cookies"). ? Click "OK". Mac IE 5.x 1. Click *Edit* 2. Select *Preferences* 3. Under the Receiving Files option, select *Cookies* 4. Under "When receiving cookies:" select the desired level of cookie acceptance 5. Under "When receiving cookies:" select the desired level of cookie acceptance 6. Click *OK *to finish Mac IE 4.x 1. Go to My AOL on the menu bar 2. Pick *WWW* 3. Go to the *Advanced Settings* option on the Category menu 4. Click *"Cookies"* 5. When receiving cookies: Click *"Never Ask"* 6. Click *OK* AOL 9.0 1. From the AOL Toolbar, select *Settings*. 2. Select *Internet [Web] Options* 3. Select *Use your Internet Explorer Settings *to set advanced browser options. 4. Select the *Privacy *tab 5. Select *Advanced* 6. *Deselect* override automatic cookie handling button 7. Click *OK* to exit. AOL 8.0 1. From the AOL Toolbar, select *Settings*. 2. Select *Preferences* 3. Select *Internet Properties (WWW)* 4. Select the *Privacy *tab 5. Select *Advanced* 6. *Deselect* override automatic cookie handling button 7. Click *OK* to exit. AOL 7.0 with IE 6.x 1. From the AOL Toolbar, select *Settings*. 2. Select *Preferences* 3. Select *Internet Properties (WWW)* 4. Select the *Privacy *tab 5. Select *Advanced* 6. *Deselect *override automatic cookie handling button 7. Click *OK* to exit. AOL 7.0 with IE 5.5 1. From the AOL Toolbar, select *Settings*. 2. Select *Preferences* 3. Select *Internet Properties (WWW)* 4. Select the *Security *tab 5. Select the *Custom Level *tab 6. Under "Allow Cookies that are stored on your computer" click * "Enable"* 7. Under "Allow per-session cookies (not stored)" click *"Enable"* 8. Select *OK*, Yes you want to save the settings AOL 6.0 1. From the AOL Toolbar, select *Settings* 2. Select *Preferences* 3. Select *Internet Properties (WWW)* 4. Select the *Security *tab 5. Select the *Custom Level *tab 6. Under "Allow Cookies that are stored on your computer" click * "Enable"* 7. Under "Allow per-session cookies (not stored)" click *"Enable"* 8. Select *OK*, Yes you want to save the settings AOL 5.0 1. Go to *My AOL* 2. Pick *WWW* 3. Click the *Security tab* 4. Go to *Custom Level* 5. Scroll down to find *Cookie* 6. Click *"Enable"* 7. Click *OK* AOL 4.0 1. Click on *Preferences* 2. Select on the *WWW* button 3. Click on the *Advanced* tab 4. Select the *"Accept all cookies"* checkbox AOL for Windows 3.1 Browser does not give you the ability to turn off cookies -------------- next part -------------- An HTML attachment was scrubbed... URL: From jasonwryan at gmail.com Mon Jul 18 16:35:23 2011 From: jasonwryan at gmail.com (Jason Ryan) Date: Tue, 19 Jul 2011 09:35:23 +1200 Subject: [Vimprobable-users] cookies - not enabled In-Reply-To: References: Message-ID: <20110718213523.GA2801@Longbow.dev.ssc.govt.nz> On 18/07/11 at 02:26pm, Anonymous wrote: > hi all, > > so I got a message that the browser I use doesn't support cookies any idea > why how I fix this? It was when I tried to log in to www.ieee-pvsc.org. > Did you create the cookie file in $HOME/.config/vimprobable/cookies as per the man page? -- Jason Ryan 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 evan54 at gmail.com Mon Jul 18 16:50:15 2011 From: evan54 at gmail.com (Anonymous) Date: Mon, 18 Jul 2011 14:50:15 -0700 Subject: [Vimprobable-users] cookies - not enabled In-Reply-To: <20110718213523.GA2801@Longbow.dev.ssc.govt.nz> References: <20110718213523.GA2801@Longbow.dev.ssc.govt.nz> Message-ID: hadn't... but did now and the problem still remains: here is how to reproduce my results: go to: http://www.ieee-pvsc.org/ePVSC/ and click on login (no need to enter username pwd to reproduce...) and this is what is written in the cookies file: www.ieee-pvsc.org FALSE /ePVSC FALSE 1311073680 SPLTRAK_onsite_registration no www.ieee-pvsc.org FALSE / FALSE 1311073680 PHPSESSID 171S66S85S181E1311025680 www.ieee-pvsc.org FALSE /ePVSC FALSE 1311073680 SPLTRAKsid 171S66S85S181E1311025680 best, eVan On Mon, Jul 18, 2011 at 2:35 PM, Jason Ryan wrote: > On 18/07/11 at 02:26pm, Anonymous wrote: > > hi all, > > > > so I got a message that the browser I use doesn't support cookies any > idea > > why how I fix this? It was when I tried to log in to www.ieee-pvsc.org. > > > > Did you create the cookie file in $HOME/.config/vimprobable/cookies as per > the > man page? > > > > -- > > Jason Ryan > http://jasonwryan.com/ > > _______________________________________________ > 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 jasonwryan at gmail.com Mon Jul 18 16:59:15 2011 From: jasonwryan at gmail.com (Jason Ryan) Date: Tue, 19 Jul 2011 09:59:15 +1200 Subject: [Vimprobable-users] cookies - not enabled In-Reply-To: References: <20110718213523.GA2801@Longbow.dev.ssc.govt.nz> Message-ID: <20110718215915.GB2801@Longbow.dev.ssc.govt.nz> On 18/07/11 at 02:50pm, Anonymous wrote: > hadn't... but did now and the problem still remains: > > here is how to reproduce my results: > > go to: > > http://www.ieee-pvsc.org/ePVSC/ > > and click on login (no need to enter username pwd to reproduce...) > Does the same thing happen if you do enter a correct username and password? Cookies work fine for me in all of the other sites I visit that require them. Also, their list of browsers looks like a throwback to 1986 - I wouldn't expect too much in the way of functionality from the rest of the site. A favour: please don't top post - it renders threads virtually unreadable. Cheers, -- Jason Ryan 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 evan54 at gmail.com Mon Jul 18 17:04:55 2011 From: evan54 at gmail.com (Anonymous) Date: Mon, 18 Jul 2011 15:04:55 -0700 Subject: [Vimprobable-users] cookies - not enabled In-Reply-To: <20110718215915.GB2801@Longbow.dev.ssc.govt.nz> References: <20110718213523.GA2801@Longbow.dev.ssc.govt.nz> <20110718215915.GB2801@Longbow.dev.ssc.govt.nz> Message-ID: On Mon, Jul 18, 2011 at 2:59 PM, Jason Ryan wrote: > On 18/07/11 at 02:50pm, Anonymous wrote: > > hadn't... but did now and the problem still remains: > > > > here is how to reproduce my results: > > > > go to: > > > > http://www.ieee-pvsc.org/ePVSC/ > > > > and click on login (no need to enter username pwd to reproduce...) > > > Does the same thing happen if you do enter a correct username and password? > > Cookies work fine for me in all of the other sites I visit that require > them. > > Also, their list of browsers looks like a throwback to 1986 - I wouldn't > expect > too much in the way of functionality from the rest of the site. > > A favour: please don't top post - it renders threads virtually unreadable. > > Cheers, > > -- > > Jason Ryan > http://jasonwryan.com/ > > _______________________________________________ > Vimprobable-users mailing list > Vimprobable-users at vimprobable.org > http://vimprobable.org/mailman/listinfo/vimprobable-users > > sorry about the top posting thing... so yeah with other websites was fine... even before (I think) adding those files the man page suggests... for example i can log into gmail just fine. and yes the same thing happens even if I enter a correct username and pwd... any other ideas? best, eVan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jasonwryan at gmail.com Mon Jul 18 17:35:56 2011 From: jasonwryan at gmail.com (Jason Ryan) Date: Tue, 19 Jul 2011 10:35:56 +1200 Subject: [Vimprobable-users] cookies - not enabled In-Reply-To: References: <20110718213523.GA2801@Longbow.dev.ssc.govt.nz> <20110718215915.GB2801@Longbow.dev.ssc.govt.nz> Message-ID: <20110718223556.GC2801@Longbow.dev.ssc.govt.nz> On 18/07/11 at 03:04pm, Anonymous wrote: > On Mon, Jul 18, 2011 at 2:59 PM, Jason Ryan wrote: > > > On 18/07/11 at 02:50pm, Anonymous wrote: > > > hadn't... but did now and the problem still remains: > > > > > > here is how to reproduce my results: > > > > > > go to: > > > > > > http://www.ieee-pvsc.org/ePVSC/ > > > > > > and click on login (no need to enter username pwd to reproduce...) > > > > > Does the same thing happen if you do enter a correct username and password? > > > > Cookies work fine for me in all of the other sites I visit that require > > them. > > > > Also, their list of browsers looks like a throwback to 1986 - I wouldn't > > expect > > too much in the way of functionality from the rest of the site. > > > > A favour: please don't top post - it renders threads virtually unreadable. > > > > Cheers, > > > > -- > > > > Jason Ryan > > http://jasonwryan.com/ > > > > _______________________________________________ > > Vimprobable-users mailing list > > Vimprobable-users at vimprobable.org > > http://vimprobable.org/mailman/listinfo/vimprobable-users > > > > > > sorry about the top posting thing... > > so yeah with other websites was fine... even before (I think) adding those > files the man page suggests... for example i can log into gmail just fine. > > and yes the same thing happens even if I enter a correct username and pwd... > any other ideas? > Sorry - not really. You could try setting another useragent or, failing that, use you back up browser. -- Jason Ryan 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 evan54 at gmail.com Mon Jul 18 18:15:27 2011 From: evan54 at gmail.com (Anonymous) Date: Mon, 18 Jul 2011 16:15:27 -0700 Subject: [Vimprobable-users] cookies - not enabled In-Reply-To: <20110718223556.GC2801@Longbow.dev.ssc.govt.nz> References: <20110718213523.GA2801@Longbow.dev.ssc.govt.nz> <20110718215915.GB2801@Longbow.dev.ssc.govt.nz> <20110718223556.GC2801@Longbow.dev.ssc.govt.nz> Message-ID: On Mon, Jul 18, 2011 at 3:35 PM, Jason Ryan wrote: > On 18/07/11 at 03:04pm, Anonymous wrote: > > On Mon, Jul 18, 2011 at 2:59 PM, Jason Ryan > wrote: > > > > > On 18/07/11 at 02:50pm, Anonymous wrote: > > > > hadn't... but did now and the problem still remains: > > > > > > > > here is how to reproduce my results: > > > > > > > > go to: > > > > > > > > http://www.ieee-pvsc.org/ePVSC/ > > > > > > > > and click on login (no need to enter username pwd to reproduce...) > > > > > > > Does the same thing happen if you do enter a correct username and > password? > > > > > > Cookies work fine for me in all of the other sites I visit that require > > > them. > > > > > > Also, their list of browsers looks like a throwback to 1986 - I > wouldn't > > > expect > > > too much in the way of functionality from the rest of the site. > > > > > > A favour: please don't top post - it renders threads virtually > unreadable. > > > > > > Cheers, > > > > > > -- > > > > > > Jason Ryan > > > http://jasonwryan.com/ > > > > > > _______________________________________________ > > > Vimprobable-users mailing list > > > Vimprobable-users at vimprobable.org > > > http://vimprobable.org/mailman/listinfo/vimprobable-users > > > > > > > > > > sorry about the top posting thing... > > > > so yeah with other websites was fine... even before (I think) adding > those > > files the man page suggests... for example i can log into gmail just > fine. > > > > and yes the same thing happens even if I enter a correct username and > pwd... > > any other ideas? > > > Sorry - not really. You could try setting another useragent or, failing > that, > use you back up browser. > > -- > Jason Ryan > http://jasonwryan.com/ > > _______________________________________________ > Vimprobable-users mailing list > Vimprobable-users at vimprobable.org > http://vimprobable.org/mailman/listinfo/vimprobable-users > > tried various useragents... but no luck... maybe i'm just doing it wrong.. I basically changed the config.h file where it said: #define USER_AGENT "Vimprobable/" VERSION to #define USER_AGENT "Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20100101 Firefox/5.0" anyway I'm just going to use a backup browser... best -------------- next part -------------- An HTML attachment was scrubbed... URL: From jasonwryan at gmail.com Mon Jul 18 18:26:37 2011 From: jasonwryan at gmail.com (Jason Ryan) Date: Tue, 19 Jul 2011 11:26:37 +1200 Subject: [Vimprobable-users] cookies - not enabled In-Reply-To: References: <20110718213523.GA2801@Longbow.dev.ssc.govt.nz> <20110718215915.GB2801@Longbow.dev.ssc.govt.nz> <20110718223556.GC2801@Longbow.dev.ssc.govt.nz> Message-ID: <20110718232636.GD2801@Longbow.dev.ssc.govt.nz> On 18/07/11 at 04:15pm, Anonymous wrote: > tried various useragents... but no luck... maybe i'm just doing it wrong.. > > I basically changed the config.h file where it said: > > #define USER_AGENT "Vimprobable/" VERSION > > to > > #define USER_AGENT "Mozilla/5.0 (X11; Linux > x86_64; rv:5.0) Gecko/20100101 Firefox/5.0" > > anyway I'm just going to use a backup browser... > For the record, you can set it on the fly with :set useragent = $string or include it in your vimprobablerc (without the colon). -- Jason Ryan 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 Tue Jul 19 01:13:19 2011 From: hannes at yllr.net (Hannes =?ISO-8859-1?Q?Sch=FCller?=) Date: Tue, 19 Jul 2011 08:13:19 +0200 Subject: [Vimprobable-users] cookies - not enabled In-Reply-To: <20110718232636.GD2801@Longbow.dev.ssc.govt.nz> References: <20110718213523.GA2801@Longbow.dev.ssc.govt.nz> <20110718215915.GB2801@Longbow.dev.ssc.govt.nz> <20110718223556.GC2801@Longbow.dev.ssc.govt.nz> <20110718232636.GD2801@Longbow.dev.ssc.govt.nz> Message-ID: <20110719081319.5d3d7c9f@yllr.net> Hi! Jason Ryan wrote: > For the record, you can set it on the fly with :set useragent = > $string or include it in your vimprobablerc (without the colon). Since his default user agent is Vimprobable/VERSION, I guess he's using Vimprobable 1. Hannes From hannes at yllr.net Tue Jul 19 01:18:50 2011 From: hannes at yllr.net (Hannes =?ISO-8859-1?Q?Sch=FCller?=) Date: Tue, 19 Jul 2011 08:18:50 +0200 Subject: [Vimprobable-users] cookies - not enabled In-Reply-To: References: <20110718213523.GA2801@Longbow.dev.ssc.govt.nz> Message-ID: <20110719081850.5f552457@yllr.net> Anonymous wrote: > www.ieee-pvsc.org FALSE /ePVSC FALSE 1311073680 > SPLTRAK_onsite_registration no > www.ieee-pvsc.org FALSE / FALSE 1311073680 PHPSESSID > 171S66S85S181E1311025680 > www.ieee-pvsc.org FALSE /ePVSC FALSE 1311073680 > SPLTRAKsid 171S66S85S181E1311025680 If anything, this shows that whatever is the problem, it is not lack of cookie support. Debugging this would require access to the server logs to see what is actually happening on their side - most likely access to their script source, too. Hannes From evan54 at gmail.com Tue Jul 19 09:31:09 2011 From: evan54 at gmail.com (Anonymous) Date: Tue, 19 Jul 2011 07:31:09 -0700 Subject: [Vimprobable-users] cookies - not enabled In-Reply-To: <20110719081850.5f552457@yllr.net> References: <20110718213523.GA2801@Longbow.dev.ssc.govt.nz> <20110719081850.5f552457@yllr.net> Message-ID: 2011/7/18 Hannes Sch?ller > Anonymous wrote: > > www.ieee-pvsc.org FALSE /ePVSC FALSE 1311073680 > > SPLTRAK_onsite_registration no > > www.ieee-pvsc.org FALSE / FALSE 1311073680 PHPSESSID > > 171S66S85S181E1311025680 > > www.ieee-pvsc.org FALSE /ePVSC FALSE 1311073680 > > SPLTRAKsid 171S66S85S181E1311025680 > > If anything, this shows that whatever is the problem, it is not > lack of cookie support. Debugging this would require access to the > server logs to see what is actually happening on their side - most > likely access to their script source, too. > > Hannes > > > > > > > _______________________________________________ > Vimprobable-users mailing list > Vimprobable-users at vimprobable.org > http://vimprobable.org/mailman/listinfo/vimprobable-users > thanks for the info and yes I can confirm using vimprobable1. Also, I "resolved" the issue by using a different browser. best -------------- next part -------------- An HTML attachment was scrubbed... URL: From rm at deconfused.org Fri Jul 22 16:20:16 2011 From: rm at deconfused.org (Ryan Mullen) Date: Fri, 22 Jul 2011 17:20:16 -0400 Subject: [Vimprobable-users] Status of maintainership Message-ID: Hi, What's the state of maintainership for vimprobable2? I can't seem to git clone from vimprobable.org. Cloning from Thomas Adams's GitHub works fine. Is this the correct repo? Is the website being maintained, and by whom? Thomas Adams's GitHub states "Whilst I'll continue to automatically keep this in sync, please note that I do not do any development on this project anymore whatsoever. This means DO NOT BOTHER ME WITH ISSUES, PULL-REQUESTS or general programming advice for Vimprobable. I simply am not interested. You'll be ignored." Is Hannes the official maintainer? Are the patches posted to the list being applied to the git repo? Sorry for the questions, Ryan From rm at deconfused.org Fri Jul 22 16:23:27 2011 From: rm at deconfused.org (Ryan Mullen) Date: Fri, 22 Jul 2011 17:23:27 -0400 Subject: [Vimprobable-users] Status of maintainership In-Reply-To: References: Message-ID: Sorry - answered some of my own questions. > I can't seem to git clone from vimprobable.org. This eventually worked. I didn't give it long enough. > Is this the correct repo? The vimprobable.org and GitHub repos appear to be in sync. Regards. From thomas at xteddy.org Fri Jul 22 16:24:50 2011 From: thomas at xteddy.org (Thomas Adam) Date: Fri, 22 Jul 2011 22:24:50 +0100 Subject: [Vimprobable-users] Fw: vimprobable download path In-Reply-To: <1311369306.14177.YahooMailNeo@web122204.mail.ne1.yahoo.com> References: <1311368972.60964.YahooMailNeo@web122213.mail.ne1.yahoo.com> <1311369306.14177.YahooMailNeo@web122204.mail.ne1.yahoo.com> Message-ID: <20110722212448.GA2251@debian.ttn6tadam> Hi, [ Adding the Vimprobable mailing list in to the Cc -- why is this even off-list to begin with? ] On Fri, Jul 22, 2011 at 02:15:06PM -0700, B Raspian wrote: > Hi, > > I was wondering if you knew what was needed to make the download path > patches you wrote work with vimprobable. ?Any help is appreciated! You're the second person to ask me independently of this. I don't know why this is. Don't do it. Just use the mailing list. There's nothing wrong with the patch series I sent out. It worked quite well, barring a few bugs. The big problem with it was that it touched upon the behemoth which is complete() -- as soon as you do that, you need to either stop, or restructure complete(). I got far in doing that, as it happened, but time was always against me. Don't be blind-sighted by that the, I'll reiterate again that the code is quite robust in doing what was originally intended. As far as I know it's still working fine on my fork of Vimprobable I have here, and on Github. > Why did you leave? Can you finish the patches off? No. I won't do that, simply because my time is limited. There's only so much turd-polishing I'm prepared to do before it ends up a waste of my time, not to mention the fact that I've noticed since that some of my commits were reverted without any discussion or questioning. Ask yourself if that's the sort of project you want to associate yourself in, where things seem to go under the radar. It's annoying more than anything. Take the patch series, rewrite it, or improve upon it. Do whatever you want. Just please, do not involve me in whatever you do. I do not care one bit for this project's development, other than I am sure it will succeed. I'm simply busy elsewhere on other things which I deem more important. I'll continue to maintain the mirror of vimprobable on Github -- it's automatically setup that way for ages. -- 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 Fri Jul 22 16:53:44 2011 From: thomas at xteddy.org (Thomas Adam) Date: Fri, 22 Jul 2011 22:53:44 +0100 Subject: [Vimprobable-users] Fw: Fw: vimprobable download path In-Reply-To: <1311370699.93210.YahooMailNeo@web122218.mail.ne1.yahoo.com> References: <1311368972.60964.YahooMailNeo@web122213.mail.ne1.yahoo.com> <1311369306.14177.YahooMailNeo@web122204.mail.ne1.yahoo.com> <20110722212448.GA2251@debian.ttn6tadam> <1311370590.26715.YahooMailNeo@web122208.mail.ne1.yahoo.com> <1311370699.93210.YahooMailNeo@web122218.mail.ne1.yahoo.com> Message-ID: <20110722215343.GB2251@debian.ttn6tadam> On Fri, Jul 22, 2011 at 02:38:19PM -0700, B Raspian wrote: > hi, > > OK - thank you for that. If I wanted to resurrect your patches, what do I > need to do? You will need to clone my repo on Github: % git clone git://github.com/ThomasAdam/vimprobable.git Then you will need to checkout the branch with the patches on it: % git checkout -t origin/ta/runtime-download-path I would recommend you rebase this on top of the vimprobable2 branch though, it's likely stagnated with further developments: % git branch vimprobable2 origin/vimprobable2 % git rebase vimprobable2 (You might need to fix-up any conflicts here. Good luck.) >From that point on, do what you like with that's there. I wanted originally to split off completion into its own .c and .h file but note that: * You'll need to resolve #include nightmare. * You'll need to add #include guards to .h files That's going to be interesting -- main.c needs splitting out as it is anyway, but that's a separate task. Overall, the completion series might benefit from it, but don't consider doing this until you end up fixing the lack of include guards in the header files. When you've done that, you'll likely have to then fix the problem that .h files include other .h files, etc., etc., rather than the .c files using them directly. It's doable, but again, a fair amount of work. I don't recall without looking at the code the reusable components of it, but I recall writing a __canonicalise_dir_path() function for generically handling paths, so I am sure making this tab-completion matching more generic would be possible. Certainly in my unfinished patches I have here, I butchered complete() to such an extent that it got split out into four functions, and it became nothing more than a switch statement, delegating to those functions for whichever action was needed. Conflating that though with allowing runtime download paths with tab-completion shouldn't be a barrier to getting them included, but given that touching complete() in any form is like walking on egg-shells, I would still strongly recommend refacturing that before you attempt anything else. > Also, out of interest, what was reverted? If you look at the git history, you'll see this: 234e59ad06ae1f9dbf503a390c739d6746f9f6c9 Which is absolutely the *wrong* thing to do. It might be controversial to think that free-by-callee is a bad thing, but so much of the existing code-base assumed that anyway, that adding support for that was not only logical, but the right thing to do. It was accepted, and we gradually started to migrate callers over to it. This blind revert was actually unnecessary given a somewhat buried patch I even posted to the list as part of Kim Albert's hint series originally. Go and look in the archives for it. But it would have helped with the problem, rather than silently ignoring it. This is the problem you have when development happens in one place; the only glimmer of hope you have of ever seeing patches from the maintainer is if he wishes to publish them for comment to the list -- sometimes he does, other times he does not. The only clue you have to what has happened to form a release is *after* it's gone out. But which time, the incentive to do anything with it diminishes, and people like me walk away, finding better things to do with their time. Should you feel that way, I suggest Jumunji or Chromium to you. Don't bother me again with this, please. I'm done 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 hannes at yllr.net Fri Jul 22 17:26:29 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 23 Jul 2011 00:26:29 +0200 Subject: [Vimprobable-users] Status of maintainership In-Reply-To: References: Message-ID: <20110723002629.4c951792@workstation> Hi Ryan! Ryan Mullen wrote: > What's the state of maintainership for vimprobable2? > [...] > Is Hannes the official maintainer? Are the patches posted to the list > being applied to the git repo? Patches are being posted & applied by me as usual, don't worry. As you can read here on the list, the next release will contain a few functional enhancements by me (new hint modes and external URI handlers) as well as others (Daniel Carl) plus some minor bugfixes. Before I get it out, though, I want to finish the URI handling routines. Seeing as the last new release happened only four weeks ago, I'm not sure where the sudden doubt is coming from, to be honest. 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 Jul 22 18:24:25 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 23 Jul 2011 01:24:25 +0200 Subject: [Vimprobable-users] "free" handling change / project management (was: vimprobable download path) In-Reply-To: <20110722212448.GA2251@debian.ttn6tadam> References: <1311368972.60964.YahooMailNeo@web122213.mail.ne1.yahoo.com> <1311369306.14177.YahooMailNeo@web122204.mail.ne1.yahoo.com> <20110722212448.GA2251@debian.ttn6tadam> Message-ID: <20110723012425.15d5dea0@workstation> Thomas, I must say I'm quite surprised by this. I had wondered already what the reason behind you suddenly leaving without a word and dropping all these strange hints since then, but well, let's say I didn't expect anything like this. Thomas Adam wrote: > not to mention the fact that I've noticed since that some of my > commits were reverted without any discussion or questioning. Ask > yourself if that's the sort of project you want to associate yourself > in, where things seem to go under the radar. It's annoying more than > anything. > >> Also, out of interest, what was reverted? > > If you look at the git history, you'll see this: > > 234e59ad06ae1f9dbf503a390c739d6746f9f6c9 Alright, so I dug through the mailing list archives. Your criticism is spot-on - I missed posting this on the list for review. You've got my apologies for this oversight, I have to take responsibility. I find it sad, though, that after all this time, you seem to assume there is some sort of intentional policy on my side for doing this. Ever since this mailing list was established, I've posted my changes for review here just like anyone else does. Mostly, feedback has been zero, so I applied them after some grace period. In this case, I missed it. I can't remember the reason and I have no excuse for it. Nevertheless, this is something which you could have easily learned by dropping me a short line (or sending the same question to the list) -- all I would have said would have been an embarassed "oops". As you can see, I'm continuing to post my change proposals to the list. The ones I'm planning for the next release can also be found right here on the list. There is no big conspiracy, just human error which sometimes happens, as annoying as it might be. I notice, though, that you admit yourself that this revert occured *after* you had already left. So I am curious whether there was anything else. > Which is absolutely the *wrong* thing to do. It might be > controversial to think that free-by-callee is a bad thing, but so > much of the existing code-base assumed that anyway, that adding > support for that was not only logical, but the right thing to do. It > was accepted, and we gradually started to migrate callers over to > it. This blind revert was actually unnecessary given a somewhat > buried patch I even posted to the list as part of Kim Albert's hint > series originally. Go and look in the archives for it. But it would > have helped with the problem, rather than silently ignoring it. So, to give you my rationale for reverting this: It made the command line history non-functional, because under some circumstances, elements of that history struct were being free'd when they shouldn't have. This lead to jumps to undefined memory. Now, I'm sure there would have been ways to fix this bug one way or the other. As you might remember, though, I was never too thrilled about free'ing memory in an asymmetric way. To quote the relevant part from the old discussion: >> > Albert Kim: >> > As per Thomas Adam's suggestion, I had script just free the strings >> > of the arg passed into it, so that it's not forgotten in in other >> > places in the code. I do this simply by: >> > >> > if (arg->s) >> > g_free(arg->s); >> > >> > However, if people add code like above where arg->s is on the >> > stack, the code is likely to segfault. Any suggestions on how to >> > get around this? >> >> Hannes Sch?ller: >> I don't think there is a perfect solution there. Maybe it's simply >> not a good idea to handle memory allocation / freeing >> asymmetricly. > > Thomas Adam: > Heh. Before this patch, and others in the past where I've done this, > there were too many instances of g_strconcat(), g_strdup() and other > variants which were assiged to any old a.s or a->s and then never > free()d again. The lesser of two evils is to pick one. > > At the time, free()ing from the place the thing was used in was easier > than to keep adding free() or g_free() time and again where it was > used. The nice thing about this patch, and others is that you then > get the clean-ups from the original malloc()ed memory for, umm, > free. :) Since even you said "at the time, it was easier", I would never have assumed you feel strongly about this issue. It was one of the many issues which I put on my "todo" list then to fix more cleanly once I have more time -- while accepting the quick fix provided by free'ing in the echo function. When the bug caused by this was noticed, well, I took that time and did a fix which fixed both issues. Note that it was not just a revert of the original change, but also fixes the problem which was the reason this change was introduced in the first place. A fix which, in my view, is much, much cleaner than the intermediate attempt. Regardless of the discussion about which option is better, see my comment above about the (incorrect) way this change/fix/revert was applied/handled by me. These are different levels of discussion. > I do not care one bit for this project's development, other than I am > sure it will succeed. I'm simply busy elsewhere on other things which > I deem more important. > > This is the problem you have when development happens in one place; > the only glimmer of hope you have of ever seeing patches from the > maintainer is if he wishes to publish them for comment to the list -- > sometimes he does, other times he does not. The only clue you have > to what has happened to form a release is *after* it's gone out. But > which time, the incentive to do anything with it diminishes, and > people like me walk away, finding better things to do with their time. > > Don't bother me again with this, please. I'm done here. Again, I believe you are severely overreacting here. I don't see any issues which couldn't have been (and cannot) be solved with just some minor improvements of communication. As I said, if anything I do bothers you, just say it openly. I'm not someone to take things personally, especially if the issues raised are completely valid (like the one which apparantely caused your discomfort in this case). What irritates me is that you abandon the project without saying a word (either publicly or privately), and then suddely produce such an outburst of -- quite frankly -- uncalled for personal attacks. To any non-involved subscriber, this has to look as if there is some huge personal vendetta, ego trip or whatever you want to call it killing of the whole project! Please, if you've got things to say, by all means, say them, but try to keep them at a basic level of civility. I don't think there is any need for such bad blood. You and anyone else has got my word that I'm trying to manage this project as transparent as my faulty human nature and, yes, also limited time allows. I hold no grudges. If you actually stand by your decision, the only thing left for me to do is to thank you once again for your contributions to the project! Of course, what projects you consider worthy of your time is at your own discretion. Rest assured, Vimprobable will continue one way or the other. 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 Sat Jul 23 05:01:29 2011 From: mtreibton at googlemail.com (Michael Treibton) Date: Sat, 23 Jul 2011 10:01:29 +0000 Subject: [Vimprobable-users] "free" handling change / project management (was: vimprobable download path) In-Reply-To: <20110723012425.15d5dea0@workstation> References: <1311368972.60964.YahooMailNeo@web122213.mail.ne1.yahoo.com> <1311369306.14177.YahooMailNeo@web122204.mail.ne1.yahoo.com> <20110722212448.GA2251@debian.ttn6tadam> <20110723012425.15d5dea0@workstation> Message-ID: hi! 2011/7/22 Hannes Sch?ller : > I notice, though, that you admit yourself that this revert occured > *after* you had already left. So I am curious whether there was > anything else. sorry to wade in, but if i can understand the git history properly this commit was made on 'wed may 25', and the next version was released 'mon jun 20'. one thing ive noticed with the git repo on vimprobable.org is i only ever see all these nice commits when you release the next version - which means theres no way anyone could have seen this change until you pushed everything to the git repo on vimprobable.org - is that right? i guess thats a problem then bec i would personaly be annoyed by this as well to see a change i thought was fine, and been working well to be reverted, especialy if the first i herd about it was when the next release came along just saying. i think in future there needs to be more discussion - it just takes a little more thought i guess :) > Now, I'm sure there would have been ways to fix this bug one way or the > other. As you might remember, though, I was never too thrilled about > free'ing memory in an asymmetric way. To quote the relevant part from > the old discussion: one thing i noticed is this: http://vimprobable.org/pipermail/vimprobable-users/2011-February/000675.html which comes from here: http://vimprobable.org/pipermail/vimprobable-users/2011-January/000602.html which (i think) is on top of: http://vimprobable.org/pipermail/vimprobable-users/2011-January/000601.html but i am not a programmer - hope thats right. so more communication needed i think! but thanks to everyone (esp Thomas) for their contributions, and its sorry to see a good person leave!! Michael From hannes at yllr.net Sun Jul 24 03:23:38 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sun, 24 Jul 2011 10:23:38 +0200 Subject: [Vimprobable-users] "free" handling change / project management (was: vimprobable download path) In-Reply-To: References: <1311368972.60964.YahooMailNeo@web122213.mail.ne1.yahoo.com> <1311369306.14177.YahooMailNeo@web122204.mail.ne1.yahoo.com> <20110722212448.GA2251@debian.ttn6tadam> <20110723012425.15d5dea0@workstation> Message-ID: <20110724102338.51207c6b@workstation> Hello Michael! Michael Treibton wrote: > 2011/7/22 Hannes Sch?ller : > > I notice, though, that you admit yourself that this revert occured > > *after* you had already left. So I am curious whether there was > > anything else. > > sorry to wade in, but if i can understand the git history properly > this commit was made on 'wed may 25', and the next version was > released 'mon jun 20'. one thing ive noticed with the git repo on > vimprobable.org is i only ever see all these nice commits when you > release the next version - which means theres no way anyone could have > seen this change until you pushed everything to the git repo on > vimprobable.org - is that right? Hence me posting my patches to this list in advance. Right now, for example, my offline repository is in perfect sync with the one online. All change proposals are on the list for review, nothing has been committed yet. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From jasonwryan at gmail.com Mon Jul 25 17:11:53 2011 From: jasonwryan at gmail.com (Jason Ryan) Date: Tue, 26 Jul 2011 10:11:53 +1200 Subject: [Vimprobable-users] Small patch for man page Message-ID: <20110725221153.GB4680@Archer> A small patch for the man page: mostly spelling and grammar but a little more detail around keybindings. Cheers, /J -- http://jasonwryan.com/ -------------- next part -------------- --- a/vimprobable2.1 2011-07-26 10:02:17.243513984 +1200 +++ b/vimprobable2.1 2011-07-26 09:57:59.403513985 +1200 @@ -3,7 +3,7 @@ .\" .TH VIMPROBABLE2 1 "JANUARY 2010" "Linux User Manuals" .SH NAME -Vimprobable \- A WWW browser based on webkit with keybindings inspired by vim, the great editor. +Vimprobable \- A WWW browser based on webkit with keybindings inspired by Vim, the great editor. .SH SYNOPSIS .B vimprobable2 @@ -31,12 +31,12 @@ .SH DESCRIPTION Vimprobable is a WWW browser that is build around the webkit library. Vimprobable is fast. Vimprobable comes without buttons and other graphic widgets. It is aimed at being controlled -as mouseless as possible. It uses keybindings that are inspired by vim, the great editor. +as mouselessly as possible. It uses keybindings that are inspired by Vim, the great editor. .PP -Just like vim, moving through the webpage can be done by entering commands by the keyboard. +Just like Vim, moving through a webpage can be done by entering commands by the keyboard. Most of these commands require just one or two keystrokes. .PP -Vimprobable mimics the ex-commandmode of vim. By entering a colon (:) commands like open, +Vimprobable mimics the ex-commandmode of Vim. By entering a colon (:) commands like open, set and map can be entered. .SH QUICK START @@ -59,8 +59,12 @@ Close current window .SH KEYBOARD BINDINGS -The default keyboard bindings are explained in this sections. These keybindings -can be changed. +The default keyboard bindings are explained in this section. These keybindings +can be changed - either at runtime by altering +.I vimprobablerc +or editing +.I keymap.h +in the source directory (in which case you will need to recompile to see changes take effect). .IP "Move through current page" Vimprobable recognizes the following motion commands: @@ -93,7 +97,7 @@ .I " " zo Zoom text out -.I " " zo +.I " " zO Zoom full content out .I " " zz @@ -135,7 +139,7 @@ Insert URL from keyboard and load it into new window .I " " u -Open a new window with the URL which has been closed last +Open a new window with the URL which was closed last .IP Search @@ -194,7 +198,7 @@ .IP ":fo[rward] and :ba[ck]" -The commands :fo, :forward, :ba and :backward moves through the browse-history +The commands :fo, :forward, :ba and :backward move through the browse-history .IP ":re[load], :re! and :reload!" @@ -212,13 +216,15 @@ .IP ":set" -Change default settings on the fly. See man vimprobablerc for the list of -settings to be changed. +Change default settings on the fly. See +.I man vimprobablerc +for the list of settings to be changed. .IP ":map" -Change default keybindings on the fly. See man vimprobablerc for the list of -mappings to be changed. +Change default keybindings on the fly. See +.I man vimprobablerc +for the list of mappings to be changed. .IP ":quit" @@ -309,7 +315,7 @@ .SH FILES -Please make sure you create these files before running the browser. +Please make sure you create these files before first running the browser. Everything but the history, bookmarks and closed files is optional. The cookies file is required if you want to use cookies. @@ -337,3 +343,5 @@ .SH "SEE ALSO" .BR vimprobablerc (1), + + -------------- 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 Tue Jul 26 11:42:42 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Tue, 26 Jul 2011 18:42:42 +0200 Subject: [Vimprobable-users] Small patch for man page In-Reply-To: <20110725221153.GB4680@Archer> References: <20110725221153.GB4680@Archer> Message-ID: <20110726184242.6eeacd7b@workstation> Jason Ryan wrote: > A small patch for the man page: mostly spelling and grammar but a > little more detail around keybindings. Thanks, Jason! Your corrections be merged into 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 hannes at yllr.net Tue Jul 26 13:06:21 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Tue, 26 Jul 2011 20:06:21 +0200 Subject: [Vimprobable-users] Basic SSL support Message-ID: <20110726200621.00532737@workstation> So... the old topic again. Quick recap: So far, Vimprobable will simply accept any SSL certificate at face value, no matter whether it can be verified or not. This, of course, makes the browser vulnerable to man-in-the-middle attacks. Since this is libsoup's default setting, this behaviour is shared with almost every other browser based on it. I dug into the documentation to see how far we can get with just libsoup itself. To my surprise, this went farther than anticipated. Find the resulting patch attached. Behaviour: - SSL certificates are checked against a CA bundle (by default: /etc/ssl/certs/ca-certificates.crt). - If verified, green background colour in the status bar (as before). - If unverified, Vimprobable will refuse to connect. New settings: - :set cabundle=/path/to/file - :set strictssl=true|false Setting strictssl to false will enable you to connect to unverified SSL encrypted sites again. The background colour of the status bar will be red instead. Pros of this solution: - Finally some actual SSL support. - No extra (external) library (like OpenSSL or GnuTLS) needed. Cons of this solution: - Exceptions of invalid certificates cannot be saved permanently. - Strict SSL checking needs to be turned off completely in this browser window to be able to connect to such sites. Might be acceptable, though, as this, of course, is only a setting which affects the single browser instance where it is explicitely set - other browser windows will continue to check strictly. So, my question to you all (and this includes all users - this is should not be decided just by short-sighted developers): Is this enough? Is this behaviour an improvement? Can we live with it? Is it good enough to finally close the SSL issue and label the next version "1.0"? Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: ssl_v1.patch Type: text/x-patch Size: 6753 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From matto at matto.nl Wed Jul 27 14:21:19 2011 From: matto at matto.nl (Matto Fransen) Date: Wed, 27 Jul 2011 21:21:19 +0200 Subject: [Vimprobable-users] Basic SSL support In-Reply-To: <20110726200621.00532737@workstation> References: <20110726200621.00532737@workstation> Message-ID: <20110727192119.GB2103@aspire.tradesystem.nl> Hi, On Tue, Jul 26, 2011 at 08:06:21PM +0200, Hannes Sch?ller wrote: > So... the old topic again. Quick recap: So far, Vimprobable will simply > accept any SSL certificate at face value, no matter whether it can be > verified or not. This, of course, makes the browser vulnerable to > man-in-the-middle attacks. Since this is libsoup's default setting, > this behaviour is shared with almost every other browser based on it. [ ... ] > Pros of this solution: > - Finally some actual SSL support. > - No extra (external) library (like OpenSSL or GnuTLS) needed. > > Cons of this solution: > - Exceptions of invalid certificates cannot be saved permanently. > - Strict SSL checking needs to be turned off completely in this browser > window to be able to connect to such sites. Might be acceptable, > though, as this, of course, is only a setting which affects the > single browser instance where it is explicitely set - other browser > windows will continue to check strictly. I am wondering how real the 'man-in-the-middle-attack' is. Is this something that is theoretical possible but never seen in the wild? Or is this something that is really a threat ? For me personally https is nice to prevent un-encrypted data being sent over the line. But if I cannot connect to my own boxes anymore (with self-created certificates) that would be a real burden... Cheers, Matto From matto at matto.nl Wed Jul 27 14:30:07 2011 From: matto at matto.nl (Matto Fransen) Date: Wed, 27 Jul 2011 21:30:07 +0200 Subject: [Vimprobable-users] [Patches] Two new hint modes In-Reply-To: <20110620222317.7220d2a4@workstation> References: <20110620222317.7220d2a4@workstation> Message-ID: <20110727193006.GA2161@aspire.tradesystem.nl> Hi, On Mon, Jun 20, 2011 at 10:23:17PM +0200, Hannes Sch?ller wrote: > based on the excellent change to use the inputbox for hinting, I have > implemented two simple new modes: > > - download link target (acticated by ";") > - yank link URL to clipboard (activated by "#") Sure looks like very useful commands :) Cheers, Matto From rm at deconfused.org Wed Jul 27 14:34:32 2011 From: rm at deconfused.org (Ryan Mullen) Date: Wed, 27 Jul 2011 15:34:32 -0400 Subject: [Vimprobable-users] Basic SSL support In-Reply-To: <20110727192119.GB2103@aspire.tradesystem.nl> References: <20110726200621.00532737@workstation> <20110727192119.GB2103@aspire.tradesystem.nl> Message-ID: Hello, On Wed, Jul 27, 2011 at 3:21 PM, Matto Fransen wrote: > I am wondering how real the 'man-in-the-middle-attack' is. Is this > something that is theoretical possible but never seen in the wild? > Or is this something that is really a threat ? It's relatively trivial. This is something a lazy script kiddie could do in a coffee shop. > For me personally https is nice to prevent un-encrypted data being > sent over the line. But if I cannot connect to my own boxes anymore > (with self-created certificates) that would be a real burden... Perhaps adding your own CA's cert to the CA cert bundle would solve this issue? Anyway, I think that manually disabling strict SSL checking is a good solution when the cert doesn't match. It would be a nice feature if we could somehow view the bad cert by downloading it to a text file to discover why it's invalid. It would also be nice if instead of an "Unable to Connect" printed to the screen, we got some more specific notification on why that is, so we know when we should try disabling strict checking. I'm not sure of the feasibility of doing something like this. Regards, Ryan From tyler at monkeypox.org Wed Jul 27 15:04:30 2011 From: tyler at monkeypox.org (R. Tyler Croy) Date: Wed, 27 Jul 2011 13:04:30 -0700 Subject: [Vimprobable-users] Basic SSL support In-Reply-To: <20110727192119.GB2103@aspire.tradesystem.nl> References: <20110726200621.00532737@workstation> <20110727192119.GB2103@aspire.tradesystem.nl> Message-ID: <20110727200430.GP13678@kiwi.local> On Wed, 27 Jul 2011, Matto Fransen wrote: > Hi, > > On Tue, Jul 26, 2011 at 08:06:21PM +0200, Hannes Sch?ller wrote: > > So... the old topic again. Quick recap: So far, Vimprobable will simply > > accept any SSL certificate at face value, no matter whether it can be > > verified or not. This, of course, makes the browser vulnerable to > > man-in-the-middle attacks. Since this is libsoup's default setting, > > this behaviour is shared with almost every other browser based on it. > > [ ... ] > > > Pros of this solution: > > - Finally some actual SSL support. > > - No extra (external) library (like OpenSSL or GnuTLS) needed. > > > > Cons of this solution: > > - Exceptions of invalid certificates cannot be saved permanently. > > - Strict SSL checking needs to be turned off completely in this browser > > window to be able to connect to such sites. Might be acceptable, > > though, as this, of course, is only a setting which affects the > > single browser instance where it is explicitely set - other browser > > windows will continue to check strictly. > > I am wondering how real the 'man-in-the-middle-attack' is. Is this > something that is theoretical possible but never seen in the wild? > Or is this something that is really a threat ? When I use Tor, I see MITM attacks regularly. It's also fairly easily to create a MITM at a coffee shop as Ryan mentioned or another open network. > For me personally https is nice to prevent un-encrypted data being > sent over the line. But if I cannot connect to my own boxes anymore > (with self-created certificates) that would be a real burden... Having tried out Hannes patch, you can still use self-signed certs just fine, much easier in fact than with Firefox :) For loading sites with self-signed certificates you can just turn off strictssl and then navigate to the site. The bar still turns red giving you some indication of what's happening, but the page will still load. There are additional concerns I have with that approach which I should probably bring up in a new mail :) Cheers - R. Tyler Croy -------------------------------------- Code: http://github.com/rtyler Chatter: http://identi.ca/agentdero http://twitter.com/agentdero -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From hannes at yllr.net Wed Jul 27 16:10:06 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Wed, 27 Jul 2011 23:10:06 +0200 Subject: [Vimprobable-users] Basic SSL support In-Reply-To: <20110727192119.GB2103@aspire.tradesystem.nl> References: <20110726200621.00532737@workstation> <20110727192119.GB2103@aspire.tradesystem.nl> Message-ID: <20110727231006.761213bf@workstation> Hi! Matto Fransen wrote: > I am wondering how real the 'man-in-the-middle-attack' is. Is this > something that is theoretical possible but never seen in the wild? > Or is this something that is really a threat ? Yes, this is definitely a very real threat. > For me personally https is nice to prevent un-encrypted data being > sent over the line. But if I cannot connect to my own boxes anymore > (with self-created certificates) that would be a real burden... I agree, this would not be acceptable. However, after failing to connect, you could simply disable the strict check for this browser instance. This, in my opinion, is in line with how certain other (commercial) browser handle it: do not connect by default, but if the user says so, override. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From hannes at yllr.net Wed Jul 27 16:11:31 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Wed, 27 Jul 2011 23:11:31 +0200 Subject: [Vimprobable-users] Basic SSL support In-Reply-To: References: <20110726200621.00532737@workstation> <20110727192119.GB2103@aspire.tradesystem.nl> Message-ID: <20110727231131.67f96c9f@workstation> Hi! Ryan Mullen wrote: > On Wed, Jul 27, 2011 at 3:21 PM, Matto Fransen wrote: > > For me personally https is nice to prevent un-encrypted data being > > sent over the line. But if I cannot connect to my own boxes anymore > > (with self-created certificates) that would be a real burden... > > Perhaps adding your own CA's cert to the CA cert bundle would solve > this issue? That would also solve the issue, yes. > Anyway, I think that manually disabling strict SSL checking is a good > solution when the cert doesn't match. It would be a nice feature if we > could somehow view the bad cert by downloading it to a text file to > discover why it's invalid. It would also be nice if instead of an > "Unable to Connect" printed to the screen, we got some more specific > notification on why that is, so we know when we should try disabling > strict checking. Hmm... right now, with the patch, I get the following message from the browser: "Unable to load page Problem occurred while loading the URL ... The SSL certificate is not trusted." I think that's pretty clear. Isn't 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 Wed Jul 27 16:15:33 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Wed, 27 Jul 2011 23:15:33 +0200 Subject: [Vimprobable-users] Basic SSL support In-Reply-To: References: <20110726200621.00532737@workstation> <20110727192119.GB2103@aspire.tradesystem.nl> Message-ID: <20110727231533.172cdcfd@workstation> Ryan Mullen wrote: > It would be a nice feature if we > could somehow view the bad cert by downloading it to a text file to > discover why it's invalid. Sorry, missed that point in my earlier reply. This is unfortunately not possible with just libsoup. I agree it would be a huge improvement. Also, that would enable storing fingerprints of certificate/URL combinations which should be trusted by the user in spite of not being trusted by any known CA. These things would still require a third-party library. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From jasonwryan at gmail.com Wed Jul 27 16:24:45 2011 From: jasonwryan at gmail.com (Jason Ryan) Date: Thu, 28 Jul 2011 09:24:45 +1200 Subject: [Vimprobable-users] [Patches] Two new hint modes In-Reply-To: <20110727193006.GA2161@aspire.tradesystem.nl> References: <20110620222317.7220d2a4@workstation> <20110727193006.GA2161@aspire.tradesystem.nl> Message-ID: <20110727212445.GA25137@Longbow.dev.ssc.govt.nz> On 27/07/11 at 09:30pm, Matto Fransen wrote: > Hi, > > On Mon, Jun 20, 2011 at 10:23:17PM +0200, Hannes Sch?ller wrote: > > > based on the excellent change to use the inputbox for hinting, I have > > implemented two simple new modes: > > > > - download link target (acticated by ";") > > - yank link URL to clipboard (activated by "#") > > Sure looks like very useful commands :) > Indeed - very handy: thanks! One issue with the yank links patch, I had to change it to: +{ GDK_SHIFT_MASK, 0, GDK_numbersign, input, {.s = "#"} }, On my keyboard you need to depress Shift to access '#' :) Cheers, /J -- Jason Ryan 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 jasonwryan at gmail.com Wed Jul 27 19:27:28 2011 From: jasonwryan at gmail.com (Jason Ryan) Date: Thu, 28 Jul 2011 12:27:28 +1200 Subject: [Vimprobable-users] [Patches] Two new hint modes In-Reply-To: <20110620222317.7220d2a4@workstation> References: <20110620222317.7220d2a4@workstation> Message-ID: <20110728002728.GA3154@Longbow.dev.ssc.govt.nz> On 20/06/11 at 10:23pm, Hannes Sch?ller wrote: > Hi, > > based on the excellent change to use the inputbox for hinting, I have > implemented two simple new modes: > > - download link target (acticated by ";") > - yank link URL to clipboard (activated by "#") > > Each is in its own (mutually exclusive) patch; let me know what you > think and if you encounter strange behaviour. > Is it possible to patch these together? (Yes, I can read "mutually exclusive"), Having both types of functionality would be great. I was just wondering if that was by design or convenience? Thanks, /J -- Jason Ryan 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 hpdeifel at gmx.de Wed Jul 27 19:46:50 2011 From: hpdeifel at gmx.de (Hans-Peter Deifel) Date: Thu, 28 Jul 2011 02:46:50 +0200 Subject: [Vimprobable-users] Basic SSL support In-Reply-To: <20110726200621.00532737@workstation> References: <20110726200621.00532737@workstation> Message-ID: <20110728004650.GB27867@deepsilver> Hi, As I said on IRC, I was quite surprised to finally see SSL support in vimprobable. Very nice work! On 20:06 Tue 26 Jul , Hannes Sch?ller wrote: [SNIP] > Cons of this solution: > - Exceptions of invalid certificates cannot be saved permanently. I think that's a bit of a problem, because users who often browse sites with invalid certificates will get annoyed and disable strict checking altogether. It would be better if they could just add an exception and continue to check all other sites with the strict setting. But I'm afraid, there's nothing that can be done about that if libsoup doesn't support it. Another thing I (and others) noticed, is that libsoup doesn't tell you _why_ a certificate failed, which is sometimes interesting. I just found these two properties in libsoup's SoupMessage class: "tls-certificate" and "tls-errors". Maybe they could be useful. [SNIP] > So, my question to you all (and this includes all users - this is > should not be decided just by short-sighted developers): Is this > enough? Is this behaviour an improvement? Can we live with it? Is it > good enough to finally close the SSL issue and label the next version > "1.0"? It's definitely a huge improvement over the current behaviour. Since changing major version numbers is "in" nowadays anyway, I'd say: Go for it. Maybe we should also issue a press release about it ;) Here are the promised comments on the code: [SNIP] > @@ -1672,18 +1672,14 @@ process_set_line(char *line) { > } > if (browsersettings[i].var != NULL) { > /* write value into internal variable */ > - /*if (browsersettings[i].intval) { > - browsersettings[i].var = atoi(my_pair.value); > - } else {*/ > - strncpy(browsersettings[i].var, my_pair.value, MAX_SETTING_SIZE); > - if (strlen(my_pair.value) > MAX_SETTING_SIZE - 1) { > - /* in this case, \0 will not have been copied */ > - browsersettings[i].var[MAX_SETTING_SIZE - 1] = '\0'; > - /* in case this string is also used for a webkit setting, make sure it's consistent */ > - my_pair.value[MAX_SETTING_SIZE - 1] = '\0'; > - give_feedback("String too long; automatically truncated!"); > - } > - /*}*/ > + strncpy(browsersettings[i].var, my_pair.value, MAX_SETTING_SIZE); > + if (strlen(my_pair.value) > MAX_SETTING_SIZE - 1) { > + /* in this case, \0 will not have been copied */ > + browsersettings[i].var[MAX_SETTING_SIZE - 1] = '\0'; > + /* in case this string is also used for a webkit setting, make sure it's consistent */ > + my_pair.value[MAX_SETTING_SIZE - 1] = '\0'; > + give_feedback("String too long; automatically truncated!"); > + } > } > if (strlen(browsersettings[i].webkit) > 0) { > /* activate appropriate webkit setting */ These changes are just cosmetic and not really related to the actual topic of the patch. I'd put them in a separate commit, but that's a matter of taste, I guess. > @@ -1721,6 +1717,20 @@ process_set_line(char *line) { > if (strlen(my_pair.what) == 14 && strncmp("completioncase", my_pair.what, 14) == 0) > complete_case_sensitive = boolval; > > + /* SSL certificate checking */ > + if (strlen(my_pair.what) == 9 && strncmp("strictssl", my_pair.what, 9) == 0) { > + if (boolval) { > + strict_ssl = TRUE; > + g_object_set(G_OBJECT(session), "ssl-strict", TRUE, NULL); > + } else { > + strict_ssl = FALSE; > + g_object_set(G_OBJECT(session), "ssl-strict", FALSE, NULL); > + } > + } > + if (strlen(my_pair.what) == 8 && strncmp("cabundle", my_pair.what, 8) == 0) { > + g_object_set(G_OBJECT(session), SOUP_SESSION_SSL_CA_FILE, ca_bundle, NULL); > + } > + Hmm, these strlen()/strncmp() checks seem to be overly conservative. As I mentioned some time ago, they are exactly equivalent to just strcmp(). But that's (a) not a problem of this patch, but the whole function and (b) again a matter of taste. > /* reload page? */ > if (browsersettings[i].reload) > webkit_web_view_reload(webview); > @@ -1893,6 +1903,12 @@ void > update_url(const char *uri) { > gboolean ssl = g_str_has_prefix(uri, "https://"); > GdkColor color; > + WebKitWebFrame *frame; > + WebKitWebDataSource *src; > + WebKitNetworkRequest *request; > + SoupMessage *msg; > + gboolean ssl_error; > + char *sslactivecolor; > #ifdef ENABLE_HISTORY_INDICATOR > char before[] = " ["; > char after[] = "]"; > @@ -1910,7 +1926,19 @@ update_url(const char *uri) { > "%s", statusfont, uri > #endif > )); > - gdk_color_parse(ssl ? sslbgcolor : statusbgcolor, &color); > + if (ssl) { > + frame = webkit_web_view_get_main_frame(webview); > + src = webkit_web_frame_get_data_source(frame); > + request = webkit_web_data_source_get_request(src); > + msg = webkit_network_request_get_message(request); > + ssl_error = soup_message_get_flags(msg) ^ SOUP_MESSAGE_CERTIFICATE_TRUSTED; I think this has to be nand instead of xor, because there are flags that have nothing to do with SSL errors (e.g. SOUP_MESSAGE_CONTENT_DECODED) > + if (ssl_error) > + sslactivecolor = sslinvalidbgcolor; > + else > + sslactivecolor = sslbgcolor; > + } > + > + gdk_color_parse(ssl ? sslactivecolor : statusbgcolor, &color); > gtk_widget_modify_bg(eventbox, GTK_STATE_NORMAL, &color); > gdk_color_parse(ssl ? sslcolor : statuscolor, &color); > gtk_widget_modify_fg(GTK_WIDGET(status_url), GTK_STATE_NORMAL, &color); > @@ -2074,6 +2102,8 @@ setup_settings() { > int len; > > session = webkit_get_default_session(); > + g_object_set(G_OBJECT(session), "ssl-ca-file", ca_bundle, NULL); > + g_object_set(G_OBJECT(session), "ssl-strict", strict_ssl, NULL); > g_object_set(G_OBJECT(settings), "default-font-size", DEFAULT_FONT_SIZE, NULL); > g_object_set(G_OBJECT(settings), "enable-scripts", enablePlugins, NULL); > g_object_set(G_OBJECT(settings), "enable-plugins", enablePlugins, NULL); Regards, HP -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 230 bytes Desc: not available URL: From hpdeifel at gmx.de Wed Jul 27 19:59:32 2011 From: hpdeifel at gmx.de (Hans-Peter Deifel) Date: Thu, 28 Jul 2011 02:59:32 +0200 Subject: [Vimprobable-users] [Patches] Two new hint modes In-Reply-To: <20110620222317.7220d2a4@workstation> References: <20110620222317.7220d2a4@workstation> Message-ID: <20110728005932.GC27867@deepsilver> On 22:23 Mon 20 Jun , Hannes Sch?ller wrote: > Hi, > > based on the excellent change to use the inputbox for hinting, I have > implemented two simple new modes: > > - download link target (acticated by ";") > - yank link URL to clipboard (activated by "#") For what it's worth: Vimperator uses ";" as a prefix key for almost all link related operations. Here is a complete list (from their manual): - ;; to focus an element - ;? to show information about an element (incomplete) - ;s to save a link's destination - ;S to save a media object - ;a to save a link's destination (prompting for save location) - ;A to save a media object (prompting for save location) - ;f to focus a frame - ;o to open its location in the current tab - ;t to open its location in a new tab - ;b to open its location in a new background tab - ;w to open its destination in a new window - ;F to follow a sequence of -delimited hints in background tabs - ;O to generate an :open with hint's URL (like O) - ;T to generate a :tabopen with hint's URL (like T) - ;W to generate a :winopen with hint's URL - ;v to view its destination source - ;V to view its destination source in the external editor - ;y to yank its destination location - ;Y to yank its text description - ;c to open its context menu - ;i to open a media object - ;I to open a media object in a new tab - ;x to display an element's title text, or alt text if none. Some of them look really useful and I also like the idea of using a dedicated prefix for these operations. Regards, HP -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 230 bytes Desc: not available URL: From ruskie at codemages.net Thu Jul 28 00:38:14 2011 From: ruskie at codemages.net (=?UTF-8?Q?Andra=C5=BE_'ruskie'_Levstik?=) Date: Thu, 28 Jul 2011 07:38:14 +0200 (CEST) Subject: [Vimprobable-users] Basic SSL support In-Reply-To: <20110726200621.00532737@workstation> References: <20110726200621.00532737@workstation> Message-ID: :2011-07-26T20:06:Hannes Sch?ller: > So... the old topic again. Quick recap: So far, Vimprobable will simply > accept any SSL certificate at face value, no matter whether it can be > verified or not. This, of course, makes the browser vulnerable to > man-in-the-middle attacks. Since this is libsoup's default setting, > this behaviour is shared with almost every other browser based on it. Technically nothing will solve this really... Quote: MITM should be seen as a general problem resulting from the presence of intermediate parties acting as proxy for clients on either side. If they are trustworthy and competent, all may be well; if they are not, nothing will be. How can one distinguish the cases? By acting as proxy and appearing as the trusted client to each side, the intermediate attacker can carry out much mischief, including various attacks against the confidentiality or integrity of the data passing through it. > Behaviour: > - SSL certificates are checked against a CA bundle (by > default: /etc/ssl/certs/ca-certificates.crt). Can it work on a certs dir? > So, my question to you all (and this includes all users - this is > should not be decided just by short-sighted developers): Is this > enough? Is this behaviour an improvement? Can we live with it? Is it > good enough to finally close the SSL issue and label the next version > "1.0"? As said don't much care for arbitrary numbers. What I'd like to see that is somewhat unrelated is per site preferences: Something like(final file format/layout left to the devs to decide): This would match only www.google.com: { "site" : "www.google.com", "match" : "exact", "scripts" : "false", "cookies" : "", "useragent" : "Whatever" , "sslbundle" : "" } This would match *.google.com and google.com: { "site" : "google.com", "match" : "approximate", "scripts" : "false", "cookies" : "", "useragent" : "Whatever2" , "sslbundle" : "" } Regards -- Andra? 'ruskie' Levstik Source Mage GNU/Linux Games/Xorg grimoire guru Re-Alpine Coordinator http://sourceforge.net/projects/re-alpine/ Geek/Hacker/Tinker I may not agree with what you say, but I'll defend your right to say it. From hannes at yllr.net Thu Jul 28 01:26:30 2011 From: hannes at yllr.net (Hannes =?ISO-8859-1?Q?Sch=FCller?=) Date: Thu, 28 Jul 2011 08:26:30 +0200 Subject: [Vimprobable-users] [Patches] Two new hint modes In-Reply-To: <20110728002728.GA3154@Longbow.dev.ssc.govt.nz> References: <20110620222317.7220d2a4@workstation> <20110728002728.GA3154@Longbow.dev.ssc.govt.nz> Message-ID: <20110728082630.573083e1@yllr.net> Hi! Jason Ryan wrote: > On 20/06/11 at 10:23pm, Hannes Sch__ller wrote: > > based on the excellent change to use the inputbox for hinting, I > > have implemented two simple new modes: > > > > - download link target (acticated by ";") > > - yank link URL to clipboard (activated by "#") > > > > Each is in its own (mutually exclusive) patch; let me know what you > > think and if you encounter strange behaviour. > > > Is it possible to patch these together? (Yes, I can read "mutually > exclusive"), Having both types of functionality would be great. > > I was just wondering if that was by design or convenience? In a release, both functions would be merged, of course. It's just that the way these patches have been created, they won't cleanly apply on top of each other. Applying both patch's contents by hand is easy. Hannes From jasonwryan at gmail.com Thu Jul 28 01:55:11 2011 From: jasonwryan at gmail.com (Jason Ryan) Date: Thu, 28 Jul 2011 18:55:11 +1200 Subject: [Vimprobable-users] [Patches] Two new hint modes In-Reply-To: <20110728082630.573083e1@yllr.net> References: <20110620222317.7220d2a4@workstation> <20110728002728.GA3154@Longbow.dev.ssc.govt.nz> <20110728082630.573083e1@yllr.net> Message-ID: <20110728065510.GA2051@Archer> On 28/07/11 at 08:26am, Hannes Sch?ller wrote: > Hi! > > Jason Ryan wrote: > > On 20/06/11 at 10:23pm, Hannes Sch__ller wrote: > > > based on the excellent change to use the inputbox for hinting, I > > > have implemented two simple new modes: > > > > > > - download link target (acticated by ";") > > > - yank link URL to clipboard (activated by "#") > > > > > > Each is in its own (mutually exclusive) patch; let me know what you > > > think and if you encounter strange behaviour. > > > > > Is it possible to patch these together? (Yes, I can read "mutually > > exclusive"), Having both types of functionality would be great. > > > > I was just wondering if that was by design or convenience? > > In a release, both functions would be merged, of course. It's just that > the way these patches have been created, they won't cleanly apply on top > of each other. Applying both patch's contents by hand is easy. > "Easy" of course is relative :) I tried hand patching the second one in (download-link), but got stuck trying to untangle this section: strncpy(followTarget, "current", 7); } else if (arg->s[0] == ',') { strncpy(followTarget, "new", 3); } else { strncpy(followTarget, "download", 8); } which conflicts with the section in the yank patch: } else { strncpy(followTarget, "copy", 4); } With no knowledge of C, I can safely report that adding another if to the download section does not compile successfully... Any pointers gratefully received. Cheers, /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 jasonwryan at gmail.com Thu Jul 28 03:47:53 2011 From: jasonwryan at gmail.com (Jason Ryan) Date: Thu, 28 Jul 2011 20:47:53 +1200 Subject: [Vimprobable-users] [Patches] Two new hint modes In-Reply-To: <20110728065510.GA2051@Archer> References: <20110620222317.7220d2a4@workstation> <20110728002728.GA3154@Longbow.dev.ssc.govt.nz> <20110728082630.573083e1@yllr.net> <20110728065510.GA2051@Archer> Message-ID: <20110728084752.GB2051@Archer> On 28/07/11 at 06:55pm, GMail wrote: > On 28/07/11 at 08:26am, Hannes Sch?ller wrote: > > Hi! > > > > Jason Ryan wrote: > > > On 20/06/11 at 10:23pm, Hannes Sch__ller wrote: > > > > based on the excellent change to use the inputbox for hinting, I > > > > have implemented two simple new modes: > > > > > > > > - download link target (acticated by ";") > > > > - yank link URL to clipboard (activated by "#") > > > > > > > > Each is in its own (mutually exclusive) patch; let me know what you > > > > think and if you encounter strange behaviour. > > > > > > > Is it possible to patch these together? (Yes, I can read "mutually > > > exclusive"), Having both types of functionality would be great. > > > > > > I was just wondering if that was by design or convenience? > > > > In a release, both functions would be merged, of course. It's just that > > the way these patches have been created, they won't cleanly apply on top > > of each other. Applying both patch's contents by hand is easy. > > > "Easy" of course is relative :) > > I tried hand patching the second one in (download-link), but got stuck trying to > untangle this section: > > > strncpy(followTarget, "current", 7); > } else if (arg->s[0] == ',') { > strncpy(followTarget, "new", 3); > } else { > strncpy(followTarget, "download", 8); > } > > which conflicts with the section in the yank patch: > > } else { > strncpy(followTarget, "copy", 4); > } > > With no knowledge of C, I can safely report that adding another if to the > download section does not compile successfully... > > Any pointers gratefully received. OK Hannes - you were right. For anyone else interested: the version I hacked together is here: http://codepad.org/uln5hu5u -- 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 danielcarl at gmx.de Thu Jul 28 17:24:10 2011 From: danielcarl at gmx.de (Daniel Carl) Date: Fri, 29 Jul 2011 00:24:10 +0200 Subject: [Vimprobable-users] [PATCH] Fix for broken scrollbars on some pages Message-ID: <20110728222404.GA8410@linnea> Hello, on some pages vimprobale shows a disfunctional scrollbar on the right (for eyample https://github.org). The patch remove such unusable scrollbars, but i don't know if i have done it in the right way. Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fixed-broken-scrollbars-on-some-pages.patch Type: text/x-diff Size: 2768 bytes Desc: not available URL: -------------- 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 Jul 29 01:11:40 2011 From: hannes at yllr.net (Hannes =?ISO-8859-1?Q?Sch=FCller?=) Date: Fri, 29 Jul 2011 08:11:40 +0200 Subject: [Vimprobable-users] Basic SSL support In-Reply-To: References: <20110726200621.00532737@workstation> Message-ID: <20110729081140.5a17995f@yllr.net> Hi! Andra__ 'ruskie' Levstik wrote: > :2011-07-26T20:06:Hannes Sch__ller: > > default: /etc/ssl/certs/ca-certificates.crt). > > Can it work on a certs dir? Sorry, no. > What I'd like to see that is somewhat unrelated is per site > preferences: Yes... this is "somewhat" unrelated ;) In my opinion, a topic for post 1.0. Hannes From hannes at yllr.net Fri Jul 29 01:23:06 2011 From: hannes at yllr.net (Hannes =?ISO-8859-1?Q?Sch=FCller?=) Date: Fri, 29 Jul 2011 08:23:06 +0200 Subject: [Vimprobable-users] Basic SSL support In-Reply-To: <20110728004650.GB27867@deepsilver> References: <20110726200621.00532737@workstation> <20110728004650.GB27867@deepsilver> Message-ID: <20110729082306.2c436e68@yllr.net> Hi! Hans-Peter Deifel wrote: > On 20:06 Tue 26 Jul , Hannes Sch__ller wrote: > [SNIP] > > Cons of this solution: > > - Exceptions of invalid certificates cannot be saved permanently. > > I think that's a bit of a problem, because users who often browse > sites with invalid certificates will get annoyed and disable strict > checking altogether. It would be better if they could just add an > exception and continue to check all other sites with the strict > setting. But I'm afraid, there's nothing that can be done about that > if libsoup doesn't support it. I agree, but even then, the situation will not be worse than it is now. > Another thing I (and others) noticed, is that libsoup doesn't tell you > _why_ a certificate failed, which is sometimes interesting. > > I just found these two properties in libsoup's SoupMessage class: > "tls-certificate" and "tls-errors". Maybe they could be useful. Good point - I will look into it! > > if (browsersettings[i].var != NULL) { > > /* write value into internal variable */ > > - /*if (browsersettings[i].intval) { > > - browsersettings[i].var = atoi(my_pair.value); > > - } else {*/ > > - strncpy(browsersettings[i].var, my_pair.value, > > MAX_SETTING_SIZE); > > - if (strlen(my_pair.value) > MAX_SETTING_SIZE - > > 1) { > > - /* in this case, \0 will not have been > > copied */ > > - browsersettings[i].var[MAX_SETTING_SIZE - > > 1] = '\0'; > > - /* in case this string is also used for a > > webkit setting, make sure it's consistent */ > > - my_pair.value[MAX_SETTING_SIZE - 1] = '\0'; > > - give_feedback("String too long; > > automatically truncated!"); > > - } > > - /*}*/ > > + strncpy(browsersettings[i].var, my_pair.value, > > MAX_SETTING_SIZE); > > + if (strlen(my_pair.value) > MAX_SETTING_SIZE - 1) { > > + /* in this case, \0 will not have been copied > > */ > > + browsersettings[i].var[MAX_SETTING_SIZE - 1] = > > '\0'; > > + /* in case this string is also used for a > > webkit setting, make sure it's consistent */ > > + my_pair.value[MAX_SETTING_SIZE - 1] = '\0'; > > + give_feedback("String too long; automatically > > truncated!"); > > + } > > } > > if (strlen(browsersettings[i].webkit) > 0) { > > /* activate appropriate webkit setting */ > > These changes are just cosmetic and not really related to the actual > topic of the patch. I'd put them in a separate commit, but that's a > matter of taste, I guess. Correct, I will split this (i.e. remove this change from this patch). > > @@ -1721,6 +1717,20 @@ process_set_line(char *line) { > > if (strlen(my_pair.what) == 14 && > > strncmp("completioncase", my_pair.what, 14) == 0) > > complete_case_sensitive = boolval; > > + /* SSL certificate checking */ > > + if (strlen(my_pair.what) == 9 && strncmp("strictssl", > > my_pair.what, 9) == 0) { > > + if (boolval) { > > + strict_ssl = TRUE; > > + g_object_set(G_OBJECT(session), "ssl-strict", > > TRUE, NULL); > > + } else { > > + strict_ssl = FALSE; > > + g_object_set(G_OBJECT(session), "ssl-strict", > > FALSE, NULL); > > + } > > + } > > + if (strlen(my_pair.what) == 8 && strncmp("cabundle", > > my_pair.what, 8) == 0) { > > + g_object_set(G_OBJECT(session), > > SOUP_SESSION_SSL_CA_FILE, ca_bundle, NULL); > > + } > > + > > Hmm, these strlen()/strncmp() checks seem to be overly conservative. > As I mentioned some time ago, they are exactly equivalent to just > strcmp(). But that's (a) not a problem of this patch, but the whole > function and (b) again a matter of taste. As Iggy Pop once said: "I like the small black marks on my hand - I'm a conservative" ;) > > + ssl_error = soup_message_get_flags(msg) ^ > > SOUP_MESSAGE_CERTIFICATE_TRUSTED; > > I think this has to be nand instead of xor, because there are flags > that have nothing to do with SSL errors (e.g. > SOUP_MESSAGE_CONTENT_DECODED) This makes sense, will change. Hannes From hannes at yllr.net Fri Jul 29 01:27:22 2011 From: hannes at yllr.net (Hannes =?ISO-8859-1?Q?Sch=FCller?=) Date: Fri, 29 Jul 2011 08:27:22 +0200 Subject: [Vimprobable-users] [PATCH] Fix for broken scrollbars on some pages In-Reply-To: <20110728222404.GA8410@linnea> References: <20110728222404.GA8410@linnea> Message-ID: <20110729082722.523f4d61@yllr.net> Hi! Daniel Carl wrote: > on some pages vimprobale shows a disfunctional scrollbar on the right > (for eyample https://github.org). The patch remove such unusable > scrollbars, but i don't know if i have done it in the right way. This looks right. I'm wondering whether this will lead to side effects/issues on some sites. Anyone wants to protest? Hannes From danielcarl at gmx.de Sat Jul 30 06:44:08 2011 From: danielcarl at gmx.de (Daniel Carl) Date: Sat, 30 Jul 2011 13:44:08 +0200 Subject: [Vimprobable-users] [PATCH] Hinting for observed elements Message-ID: <20110730114401.GA7426@linnea> Hi, i noticed, that i could not use some pages, that use tab menus. These menus are not switched by onlick properties in the elements but by eventObservers somewhere else in the page. With the path also such menus will work with hinting. I don't know if it's necessary to open normal links in an special way. For me the dispatching of the mouseevent work fine, also for links. Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fixe-hinting-to-work-on-element-with-eventobserver.patch Type: text/x-diff Size: 1765 bytes Desc: not available URL: -------------- 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 Sat Jul 30 06:49:13 2011 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 30 Jul 2011 13:49:13 +0200 Subject: [Vimprobable-users] [PATCH] Hinting for observed elements In-Reply-To: <20110730114401.GA7426@linnea> References: <20110730114401.GA7426@linnea> Message-ID: <20110730134913.3b51eef8@workstation> Hello Daniel! Daniel Carl wrote: > I don't know if it's necessary to open normal links in an special > way. For me the dispatching of the mouseevent work fine, also for > links. I think this will break opening links in a new window. Also, it will prevent the other hint modes (downloading etc.) which are currently available on the list from working. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From danielcarl at gmx.de Sat Jul 30 11:32:04 2011 From: danielcarl at gmx.de (Daniel Carl) Date: Sat, 30 Jul 2011 18:32:04 +0200 Subject: [Vimprobable-users] [PATCH] Hinting for observed elements In-Reply-To: <20110730134913.3b51eef8@workstation> References: <20110730114401.GA7426@linnea> <20110730134913.3b51eef8@workstation> Message-ID: <20110730163158.GA10210@linnea> On Sat, Jul 30, 2011 at 01:49:13PM +0200, Hannes Sch?ller wrote: > Hello Daniel! > > Daniel Carl wrote: > > I don't know if it's necessary to open normal links in an special > > way. For me the dispatching of the mouseevent work fine, also for > > links. > > I think this will break opening links in a new window. Also, it will > prevent the other hint modes (downloading etc.) which are currently > available on the list from working. > > Hannes Hello Hannes, your are right that the opening into new winow doesn't work. I forgot to test it. I have removed to duplicate code to make the code more readable. Maybe we can put an additional variable to the function to indicate to open links into new window or not. Attached patch should do the same as the current vimbrobable does, but better to read i hope. Daniel > _______________________________________________ > Vimprobable-users mailing list > Vimprobable-users at vimprobable.org > http://vimprobable.org/mailman/listinfo/vimprobable-users -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Cleaner-hinting-code.patch Type: text/x-diff Size: 1622 bytes Desc: not available URL: -------------- 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 Sun Jul 31 01:12:22 2011 From: hannes at yllr.net (Hannes =?ISO-8859-1?Q?Sch=FCller?=) Date: Sun, 31 Jul 2011 08:12:22 +0200 Subject: [Vimprobable-users] [PATCH] Hinting for observed elements In-Reply-To: <20110730163158.GA10210@linnea> References: <20110730114401.GA7426@linnea> <20110730134913.3b51eef8@workstation> <20110730163158.GA10210@linnea> Message-ID: <20110731081222.44e457aa@yllr.net> Hi! Daniel Carl wrote: > On Sat, Jul 30, 2011 at 01:49:13PM +0200, Hannes Sch__ller wrote: > > Daniel Carl wrote: > > > I don't know if it's necessary to open normal links in an special > > > way. For me the dispatching of the mouseevent work fine, also for > > > links. > > > > I think this will break opening links in a new window. Also, it will > > prevent the other hint modes (downloading etc.) which are currently > > available on the list from working. > > > > Hannes > > your are right that the opening into new winow doesn't work. I forgot > to test it. I have removed to duplicate code to make the code more > readable. Maybe we can put an additional variable to the function to > indicate to open links into new window or not. > Attached patch should do the same as the current vimbrobable does, > but better to read i hope. This looks much cleaner. It also solves your initial problem? Hannes From hannes at yllr.net Sun Jul 31 01:16:23 2011 From: hannes at yllr.net (Hannes =?ISO-8859-1?Q?Sch=FCller?=) Date: Sun, 31 Jul 2011 08:16:23 +0200 Subject: [Vimprobable-users] [Patches] Two new hint modes In-Reply-To: <20110728005932.GC27867@deepsilver> References: <20110620222317.7220d2a4@workstation> <20110728005932.GC27867@deepsilver> Message-ID: <20110731081623.0f527d32@yllr.net> Hi! Hans-Peter Deifel wrote: > On 22:23 Mon 20 Jun , Hannes Sch__ller wrote: > > based on the excellent change to use the inputbox for hinting, I > > have implemented two simple new modes: > > > > - download link target (acticated by ";") > > - yank link URL to clipboard (activated by "#") > > For what it's worth: Vimperator uses ";" as a prefix key for almost > all link related operations. Here is a complete list (from their > manual): > > - ;; to focus an element > - ;? to show information about an element (incomplete) > - ;s to save a link's destination > - ;S to save a media object > - ;a to save a link's destination (prompting for save location) > - ;A to save a media object (prompting for save location) > - ;f to focus a frame > - ;o to open its location in the current tab > - ;t to open its location in a new tab > - ;b to open its location in a new background tab > - ;w to open its destination in a new window > - ;F to follow a sequence of -delimited hints in background tabs > - ;O to generate an :open with hint's URL (like O) > - ;T to generate a :tabopen with hint's URL (like T) > - ;W to generate a :winopen with hint's URL > - ;v to view its destination source > - ;V to view its destination source in the external editor > - ;y to yank its destination location > - ;Y to yank its text description > - ;c to open its context menu > - ;i to open a media object > - ;I to open a media object in a new tab > - ;x to display an element's title text, or alt text if none. > > Some of them look really useful and I also like the idea of using a > dedicated prefix for these operations. This looks like a good concept to follow. Although most of these seem redundant and unecessary, it certainly scales much better and it avoids keymap problems. Hannes From danielcarl at gmx.de Sun Jul 31 07:35:11 2011 From: danielcarl at gmx.de (Daniel Carl) Date: Sun, 31 Jul 2011 14:35:11 +0200 Subject: [Vimprobable-users] [PATCH] Hinting for observed elements In-Reply-To: <20110731081222.44e457aa@yllr.net> References: <20110730114401.GA7426@linnea> <20110730134913.3b51eef8@workstation> <20110730163158.GA10210@linnea> <20110731081222.44e457aa@yllr.net> Message-ID: <20110731123505.GA1393@linnea> Hi! On Sun, Jul 31, 2011 at 08:12:22AM +0200, Hannes Sch?ller wrote: > Hi! > > Daniel Carl wrote: > > On Sat, Jul 30, 2011 at 01:49:13PM +0200, Hannes Sch__ller wrote: > > > Daniel Carl wrote: > > > > I don't know if it's necessary to open normal links in an special > > > > way. For me the dispatching of the mouseevent work fine, also for > > > > links. > > > > > > I think this will break opening links in a new window. Also, it will > > > prevent the other hint modes (downloading etc.) which are currently > > > available on the list from working. > > > > > > Hannes > > > > your are right that the opening into new winow doesn't work. I forgot > > to test it. I have removed to duplicate code to make the code more > > readable. Maybe we can put an additional variable to the function to > > indicate to open links into new window or not. > > Attached patch should do the same as the current vimbrobable does, > > but better to read i hope. > > This looks much cleaner. It also solves your initial problem? > > Hannes It does not solve the problem. I think i will have a look at the hinting javascript of the vimperator project and try to get it ported to vimprobable. I think, it will be easier to get the hinting work in all situations (frames, areas, dynamic javascript menus, ...) with it. Daniel -------------- 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 Sun Jul 31 12:10:58 2011 From: hannes at yllr.net (Hannes =?ISO-8859-1?Q?Sch=FCller?=) Date: Sun, 31 Jul 2011 19:10:58 +0200 Subject: [Vimprobable-users] [PATCH] Hinting for observed elements In-Reply-To: <20110731123505.GA1393@linnea> References: <20110730114401.GA7426@linnea> <20110730134913.3b51eef8@workstation> <20110730163158.GA10210@linnea> <20110731081222.44e457aa@yllr.net> <20110731123505.GA1393@linnea> Message-ID: <20110731191058.1454c768@yllr.net> Hi! Daniel Carl wrote: > I think i will have a look at the > hinting javascript of the vimperator project and try to get it ported > to vimprobable. I think, it will be easier to get the hinting work in > all situations (frames, areas, dynamic javascript menus, ...) with it. Good luck! Please bear in mind that Vimperator is written against a completely different API. I doubt you'll be able to reuse a lot. Hannes