vimprobable-users

Re: [Vimprobable-users] [Patches] Two new hint modes

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

Hi,

here is an updated version of the download hinting patch, adapted for
the new hinting backend. This does not yet explore the possibility of
using the semicolon as a prefix for different hinting modes as
Hans-Peter suggested (and as used in Vimperator), but I wanted to get
the basic functionality back first.

Hannes

Re: [Vimprobable-users] [Patches] Two new hint modes

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

Hi Hannes!

The last patch to download via hints crashes vimprobable if the hint where
fired within the inputbox_changed_cb function, this is done if you enter the
downloadmode and fire the hint only by entering the filter text wothout using
tab or shift-tab nor a number to fire the hint.

Daniel

Re: [Vimprobable-users] [Patches] Two new hint modes

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

Hi!

I've extended the download of hints to also allow to download images that
aren't descendants of a link. I don't know if there many pages where the
feature can be used, because on most sites the images are surrounded by a
link. To allow hinting for all images isn't usefull because the user can't see
if the hint on an element refers to the link url or the image source and on
sites with graphic menus we got to many hints.

Daniel

Re: [Vimprobable-users] [Patches] Two new hint modes

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

Hi Daniel!

Daniel Carl <dan...@gm...> wrote:
> The last patch to download via hints crashes vimprobable if the hint
> where fired within the inputbox_changed_cb function, this is done if
> you enter the downloadmode and fire the hint only by entering the
> filter text wothout using tab or shift-tab nor a number to fire the
> hint.

I can't reproduce this. Could anyone else test it?

Hannes

Re: [Vimprobable-users] [Patches] Two new hint modes

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

Hi Hannes!
On Mon, Sep 19, 2011 at 07:46:07PM +0200, Hannes Schüller wrote:
> I can't reproduce this. Could anyone else test it?

I tested it at work on another machine and the browser didn't crash.
I think I'll have time to get into the issue tomorrow.

Daniel

Re: [Vimprobable-users] [Patches] Two new hint modes

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

Hi!

I switched from libwebkitgtk1.3.13 to libwebkitgtk1.4.0 but vimprobable also
crashes if I download hints by only typing the Name.

Hope somebody has any idea to fix or find the problem.

Following outputs are generated by strace.

======= Working (used Tab Return to fire hint)

open("/home/daniel/git.html", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0666) = -1 EEXIST (File exists)
open("/home/daniel/git.html", O_RDWR|O_CREAT|O_LARGEFILE|O_NOFOLLOW, 0666) = 8
fstat64(8, {st_mode=S_IFREG|0644, st_size=2655, ...}) = 0
gettimeofday({1316546913, 161085}, NULL) = 0
open("/home/daniel/.goutputstream-2AU61V", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0666) = 9
fchown32(9, 1000, 1000)                 = 0
fchmod(9, 0100644)                      = 0
close(8)                                = 0
poll([{fd=6, events=POLLIN}, {fd=3, events=POLLIN}], 2, 0) = 0 (Timeout)
futex(0x8cf4cac, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x8cf4ca8, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x8cef550, FUTEX_WAKE_PRIVATE, 1) = 1
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{"<\0\2\0\275\0\300\1<\1\2\0\276\0\300\1<\4\2\0\277\0\300\1<%\2\0\300\0\300\1"..., 384}, {NULL, 0}, {"", 0}], 3) = 384
read(3, 0x8927c10, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, 0) = 0 (Timeout)
write(9, "<?xml version=\"1.0\" encoding=\"UT"..., 2655) = 2655
clock_gettime(CLOCK_MONOTONIC, {3220, 811570769}) = 0
futex(0x8cf4cac, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x8cf4ca8, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x8cef550, FUTEX_WAKE_PRIVATE, 1) = 1
read(3, 0x8927c10, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, 0) = 0 (Timeout)
fsync(9)                                = 0
unlink("/home/daniel/git.html~")        = -1 ENOENT (No such file or directory)
link("/home/daniel/git.html", "/home/daniel/git.html~") = 0
rename("/home/daniel/.goutputstream-2AU61V", "/home/daniel/git.html") = 0
fstat64(9, {st_mode=S_IFREG|0644, st_size=2655, ...}) = 0
close(9)                                = 0
clock_gettime(CLOCK_MONOTONIC, {3220, 874091005}) = 0

======= Broken (Types the name of the hint)

open("/home/daniel/git.html", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0666) = -1 EEXIST (File exists)
open("/home/daniel/git.html", O_RDWR|O_CREAT|O_LARGEFILE|O_NOFOLLOW, 0666) = 8
fstat64(8, {st_mode=S_IFREG|0644, st_size=2655, ...}) = 0
gettimeofday({1316547088, 405277}, NULL) = 0
open("/home/daniel/.goutputstream-8LOC2V", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0666) = 10
fchown32(10, 1000, 1000)                = 0
fchmod(10, 0100644)                     = 0
close(8)                                = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Speicherzugriffsfehler


Following outputs where made with valgrind.

======= Working (used Tab Return to fire hint)

==6292== Memcheck, a memory error detector
==6292== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==6292== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==6292== Command: ./vimprobable2
==6292==

(vimprobable2:6292): Gdk-CRITICAL **: IA__gdk_window_get_events: assertion `GDK_IS_WINDOW (window)' failed

(vimprobable2:6292): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed

(vimprobable2:6292): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed
==6292== Conditional jump or move depends on uninitialised value(s)
==6292==    at 0x5AFE3AC: ??? (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6292==    by 0x5AECC1A: g_signal_emit_valist (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6292==    by 0x5AECE3C: g_signal_emit_by_name (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6292==    by 0x804F5FD: script (in /home/daniel/code/c/vimprobable/vimprobable2)
==6292==    by 0x804C716: inputbox_keypress_cb (in /home/daniel/code/c/vimprobable/vimprobable2)
==6292==    by 0x53F5A03: ??? (in /usr/lib/libgtk-x11-2.0.so.0.2400.4)
==6292==    by 0x5AD1371: g_closure_invoke (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6292==    by 0x5AE4047: ??? (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6292==    by 0x5AEC8D6: g_signal_emit_valist (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6292==    by 0x5AECCC1: g_signal_emit (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6292==    by 0x552A835: ??? (in /usr/lib/libgtk-x11-2.0.so.0.2400.4)
==6292==    by 0x5542C4E: gtk_window_propagate_key_event (in /usr/lib/libgtk-x11-2.0.so.0.2400.4)
==6292== 
==6292== Use of uninitialised value of size 4
==6292==    at 0x5AFE3B1: ??? (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6292==    by 0x5AECC1A: g_signal_emit_valist (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6292==    by 0x5AECE3C: g_signal_emit_by_name (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6292==    by 0x804F5FD: script (in /home/daniel/code/c/vimprobable/vimprobable2)
==6292==    by 0x804C716: inputbox_keypress_cb (in /home/daniel/code/c/vimprobable/vimprobable2)
==6292==    by 0x53F5A03: ??? (in /usr/lib/libgtk-x11-2.0.so.0.2400.4)
==6292==    by 0x5AD1371: g_closure_invoke (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6292==    by 0x5AE4047: ??? (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6292==    by 0x5AEC8D6: g_signal_emit_valist (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6292==    by 0x5AECCC1: g_signal_emit (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6292==    by 0x552A835: ??? (in /usr/lib/libgtk-x11-2.0.so.0.2400.4)
==6292==    by 0x5542C4E: gtk_window_propagate_key_event (in /usr/lib/libgtk-x11-2.0.so.0.2400.4)
==6292== 
==6292== 
==6292== HEAP SUMMARY:
==6292==     in use at exit: 3,412,313 bytes in 126,609 blocks
==6292==   total heap usage: 164,500 allocs, 37,891 frees, 8,792,594 bytes allocated
==6292== 
==6292== LEAK SUMMARY:
==6292==    definitely lost: 8,979 bytes in 77 blocks
==6292==    indirectly lost: 18,860 bytes in 933 blocks
==6292==      possibly lost: 227,148 bytes in 1,479 blocks
==6292==    still reachable: 3,157,326 bytes in 124,120 blocks
==6292==         suppressed: 0 bytes in 0 blocks
==6292== Rerun with --leak-check=full to see details of leaked memory

======= Broken (Types the name of the hint)

==6094== Memcheck, a memory error detector
==6094== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==6094== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==6094== Command: ./vimprobable2
==6094==
==6094== Conditional jump or move depends on uninitialised value(s)
==6094==    at 0x5AFE3AC: ??? (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6094==    by 0x5AECC1A: g_signal_emit_valist (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6094==    by 0x5AECE3C: g_signal_emit_by_name (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6094==    by 0x804F5FD: script (in /home/daniel/code/c/vimprobable/vimprobable2)
==6094==    by 0x804CCE6: inputbox_changed_cb (in /home/daniel/code/c/vimprobable/vimprobable2)
==6094==    by 0x5AED48B: g_cclosure_marshal_VOID__VOID (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6094==    by 0x5AD1371: g_closure_invoke (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6094==    by 0x5AE4047: ??? (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6094==    by 0x5AECB28: g_signal_emit_valist (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6094==    by 0x5AECE3C: g_signal_emit_by_name (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6094==    by 0x5373319: ??? (in /usr/lib/libgtk-x11-2.0.so.0.2400.4)
==6094==    by 0x5AEDE47: g_cclosure_marshal_VOID__PARAM (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6094==
==6094== Use of uninitialised value of size 4
==6094==    at 0x5AFE3B1: ??? (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6094==    by 0x5AECC1A: g_signal_emit_valist (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6094==    by 0x5AECE3C: g_signal_emit_by_name (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6094==    by 0x804F5FD: script (in /home/daniel/code/c/vimprobable/vimprobable2)
==6094==    by 0x804CCE6: inputbox_changed_cb (in /home/daniel/code/c/vimprobable/vimprobable2)
==6094==    by 0x5AED48B: g_cclosure_marshal_VOID__VOID (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6094==    by 0x5AD1371: g_closure_invoke (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6094==    by 0x5AE4047: ??? (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6094==    by 0x5AECB28: g_signal_emit_valist (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6094==    by 0x5AECE3C: g_signal_emit_by_name (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6094==    by 0x5373319: ??? (in /usr/lib/libgtk-x11-2.0.so.0.2400.4)
==6094==    by 0x5AEDE47: g_cclosure_marshal_VOID__PARAM (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6094==
==6094==
==6094== Process terminating with default action of signal 11 (SIGSEGV)
==6094==  Bad permissions for mapped region at address 0x5B80A2C
==6094==    at 0x5AFE3B1: ??? (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6094==    by 0x5AECC1A: g_signal_emit_valist (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6094==    by 0x5AECE3C: g_signal_emit_by_name (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6094==    by 0x804F5FD: script (in /home/daniel/code/c/vimprobable/vimprobable2)
==6094==    by 0x804CCE6: inputbox_changed_cb (in /home/daniel/code/c/vimprobable/vimprobable2)
==6094==    by 0x5AED48B: g_cclosure_marshal_VOID__VOID (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6094==    by 0x5AD1371: g_closure_invoke (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6094==    by 0x5AE4047: ??? (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6094==    by 0x5AECB28: g_signal_emit_valist (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6094==    by 0x5AECE3C: g_signal_emit_by_name (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6094==    by 0x5373319: ??? (in /usr/lib/libgtk-x11-2.0.so.0.2400.4)
==6094==    by 0x5AEDE47: g_cclosure_marshal_VOID__PARAM (in /usr/lib/i386-linux-gnu/libgobject-2.0.so.0.2800.6)
==6094==
==6094== HEAP SUMMARY:
==6094==     in use at exit: 3,508,075 bytes in 127,041 blocks
==6094==   total heap usage: 165,317 allocs, 38,276 frees, 8,523,068 bytes allocated
==6094==
==6094== LEAK SUMMARY:
==6094==    definitely lost: 8,106 bytes in 67 blocks
==6094==    indirectly lost: 18,840 bytes in 932 blocks
==6094==      possibly lost: 343,389 bytes in 2,091 blocks
==6094==    still reachable: 3,137,740 bytes in 123,951 blocks
==6094==         suppressed: 0 bytes in 0 blocks
==6094== Rerun with --leak-check=full to see details of leaked memory
==6094==
==6094== For counts of detected and suppressed errors, rerun with: -v
==6094== Use --track-origins=yes to see where uninitialised values come from
==6094== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 206 from 13)
Getötet

During debugging webview_download_cb() was run sucessfully after that the
segmentation fault occured.

Daniel

Re: [Vimprobable-users] [Patches] Two new hint modes

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

Hi!

I forgot a backtrace I made with gdb.

#:~/code/c/vimprobable$ env G_DEBUG=fatal_criticals libtool --mode=execute gdb --args ./vimprobable2
GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/daniel/code/c/vimprobable/vimprobable2...done.
(gdb) run
Starting program: /home/daniel/code/c/vimprobable/vimprobable2
[Thread debugging using libthread_db enabled]
[New Thread 0xb4605b70 (LWP 6832)]
[New Thread 0xb3cdcb70 (LWP 6833)]
[New Thread 0xb3338b70 (LWP 6834)]

Program received signal SIGSEGV, Segmentation fault.
0xb65383b1 in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
(gdb) bt full
#0  0xb65383b1 in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#1  0xb6526c1b in g_signal_emit_valist () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#2  0xb6526e3d in g_signal_emit_by_name () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#3  0x0804f5fe in script (arg=0xbfffcd3c) at main.c:1402
        value = 0x847ee00 "download;file:///home/daniel/docs/wiki/target/linux/git.html"
        message = 0x0
        a = {i = 0, s = 0x1 <Address 0x1 out of bounds>}
        request = 0x84a1ec8
        download = 0x84862c8
#4  0x0804cce7 in inputbox_changed_cb (entry=0x80d4838, user_data=0x0) at main.c:650
        a = {i = 8, s = 0x84af3a0 "hints.createHints('Gi', 'd');"}
        text = 0x84af9f0 "Download git.html started (unknown size)..."
        length = 3
        forward = 0
#5  0xb652748c in g_cclosure_marshal_VOID__VOID () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#6  0xb650b372 in g_closure_invoke () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#7  0xb651e048 in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#8  0xb6526b29 in g_signal_emit_valist () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#9  0xb6526e3d in g_signal_emit_by_name () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#10 0xb6a2631a in ?? () from /usr/lib/libgtk-x11-2.0.so.0
No symbol table info available.
#11 0xb6527e48 in g_cclosure_marshal_VOID__PARAM () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#12 0xb650b372 in g_closure_invoke () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#13 0xb651e048 in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#14 0xb6526b29 in g_signal_emit_valist () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#15 0xb6526cc2 in g_signal_emit () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#16 0xb650d0e1 in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#17 0xb650c3ef in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#18 0xb650f379 in g_object_notify () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#19 0xb6a317dc in ?? () from /usr/lib/libgtk-x11-2.0.so.0
No symbol table info available.
---Type <return> to continue, or q <return> to quit---q
Quit
(gdb) quit

Re: [Vimprobable-users] [Patches] Two new hint modes

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

Hi!

> #2  0xb6526e3d in g_signal_emit_by_name () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0

Could you please try the attached patch? I think this function needs
another argument.

@Hannes: Why didn't you call webview_download_cb directly?

Regards,
HP

Re: [Vimprobable-users] [Patches] Two new hint modes

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

Hi Hans-Peter!
On Tue, Sep 20, 2011 at 11:36:16PM +0200, Hans-Peter Deifel wrote:
> Could you please try the attached patch? I think this function needs
> another argument.

The patch worked and vimprobable didn't crash anymore.
Nice work!

Daniel

Re: [Vimprobable-users] [Patches] Two new hint modes

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

Hans-Peter Deifel <hpd...@gm...> wrote:
> @Hannes: Why didn't you call webview_download_cb directly?

Yes, that would probably be easier - no unnecessary level of
indirection. I'll change it in the next iteration.

Hannes

Re: [Vimprobable-users] [Patches] Two new hint modes

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

Hi,

> +    { GDK_SHIFT_MASK,       0,              GDK_semicolon,  input,      {.s = ";"} },

This doesn't work for users with us layout, because ';' doesn't require
shift.

The problem is that there are two kinds of keys: Those that send a
different key symbol with shift ("Q" or ";") and those that don't
("Shift-Space").

I did a quick search and found a function that appears to do exactly
what we need:
  gdk_keymap_translate_keyboard_state()

Jumanji seems to have fixed the same problem with this patch: [1]

If I find the time and nobody is quicker, I'll try that out tomorrow
(actually tomorrow it already today).

Regards,
HP

Re: [Vimprobable-users] [Patches] Two new hint modes

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

To tired to send mails.

> Jumanji seems to have fixed the same problem with this patch: [1]

[1] http://git.pwmt.org/?p=jumanji.git;a=commitdiff;h=de4b010e9bb806c18900dd6165279b85565dc756

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

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

Hi,

this is the next iteration of my patch for additional hinting modes. It
includes the following functionality:

- ;s to save a link's destination
- ;y to yank its destination location
- ;o to open its location in the current window
- ;t or ;w to open its location in a new window
- ;O to generate an :open with hint's URL (like O)
- ;T or ;W to generate a :tabopen with hint's URL (like T)

Meaning: I took the semicolon hint modes from Vimperator which make
sense in our own setup.

If this is working for everybody (please test!), I will consolidate it
with the other patches currently floating around to create the next
release version.

Hannes

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

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

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

This works pretty fine for me too.

Daniel

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

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

Hi!
On Sat, Oct 01, 2011 at 02:38:58PM +0200, Hannes Schüller wrote:
> diff --git a/hinting.js b/hinting.js
> index e23abc6..fb45b84 100644
> --- a/hinting.js
> +++ b/hinting.js
> @@ -262,6 +262,8 @@ function Hints() {
>          {
>              case "f": result = _open(el); break;
>              case "F": result = _openNewWindow(el); break;
> +            case "s": result = _save(el); break;
> +            case "y": case "O": result = _yank(el); break;
>              default:  result = _getElemtSource(el);
>          }

This is OK, but in my opinion it is better to read an less code if we use
something like

    case "f": result = _open(el); break;
    case "F": result = _openNewWindow(el); break;
    case "s": result = "save;" + _getElemtSource(el); break;
    case "y": result = "yank;" + _getElemtSource(el); break;
    case "O": result = "colon;" + _getElemtSource(el); break;
    default:  result = _getElemtSource(el);

To not implements for each action a new function.

Daniel

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

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

Applied (with the suggested changes)

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

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

Hi,

On 14:38 Sat 01 Oct     , Hannes Schüller wrote:
> Hi,
> 
> this is the next iteration of my patch for additional hinting modes. It
> includes the following functionality:
> 
> - ;s to save a link's destination
> - ;y to yank its destination location
> - ;o to open its location in the current window
> - ;t or ;w to open its location in a new window
> - ;O to generate an :open with hint's URL (like O)
> - ;T or ;W to generate a :tabopen with hint's URL (like T)
> 
> Meaning: I took the semicolon hint modes from Vimperator which make
> sense in our own setup.

Seems to work fine, nice work!

Just a small suggestion:

> +    { 0,                    0,              GDK_semicolon,  input,      {.s = ";"} },
> +    { GDK_SHIFT_MASK,       0,              GDK_semicolon,  input,      {.s = ";"} },
[...]
> +            case ';':
> +                a.s = NULL;
> +                switch (text[1]) {
> +                    case 's':
> +                        a.s = g_strconcat("hints.createHints('", text + 2, "', 's');", NULL);
> +                        break;
> +                    case 'y':
> +                        a.s = g_strconcat("hints.createHints('", text + 2, "', 'y');", NULL);
> +                        break;
> +                    case 'o':
> +                        a.s = g_strconcat("hints.createHints('", text + 2, "', 'f');", NULL);
> +                        break;
> +                    case 't': case 'w':
> +                        a.s = g_strconcat("hints.createHints('", text + 2, "', 'F');", NULL);
> +                        break;
> +                    case 'O': case 'T': case 'W':
> +                        a.s = g_strconcat("hints.createHints('", text + 2, "', 'O');", NULL);
> +                        break;                    
> +                }
> +                break;

I don't really like hardcoded key bindings, it should be possible for the
user to change them. I propose a solution along the lines of:

 { 0, GDK_semicolon, GDK_s, input, {.s = ";s"} }

This would make the key binding completely configurable while allowing
us to keep the internal ";s" logic. Unfortunately "input" is (AFAIK)
currently not mappable, which means that you still can't change these
bindings from vimprobablerc. That could easily be implemented, though.

One problem of this approach is, that what the user types and what gets
inserted into the input box could differ, e.g. if she mapped ";f" to
input(";s"). That probably doesn't conform to the Principle Of Least
Surprise ;)


Regards,
HP

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

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

Hi!

Hans-Peter Deifel <hpd...@gm...> wrote:
> I don't really like hardcoded key bindings, it should be possible for
> the user to change them. I propose a solution along the lines of:
> 
>  { 0, GDK_semicolon, GDK_s, input, {.s = ";s"} }
> 
> This would make the key binding completely configurable while allowing
> us to keep the internal ";s" logic.

This sounds sensible, I think the element of surprise this introduces
will be bearable.

Hannes

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

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

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

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

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

This isn't a complaint/feature request.

Cheers,

/J

-- 

http://jasonwryan.com/

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

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

Hi!

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

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

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

Any opnions on this?

Hannes

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

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

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

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

Cheers,

/J

-- 

http://jasonwryan.com/

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

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

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

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

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

Daniel

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

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

Applied

Re: [Vimprobable-users] [Patches] Two new hint modes

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

Hi Hannes!

Pretty nice work!

Daniel