vimprobable-users Mailing List for Vimprobable (Page 24)
Vimprobable is a lean web browser optimised for full keyboard control
Brought to you by:
hanness
Menu
▾
▴
vimprobable-users — Mailing list for Vimprobable users
You can subscribe to this list here.
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(77) |
Sep
(44) |
Oct
(43) |
Nov
(38) |
Dec
(14) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2012 |
Jan
(40) |
Feb
(18) |
Mar
(12) |
Apr
(25) |
May
(12) |
Jun
(13) |
Jul
(17) |
Aug
(3) |
Sep
(20) |
Oct
(42) |
Nov
(9) |
Dec
(2) |
| 2013 |
Jan
(9) |
Feb
(29) |
Mar
(9) |
Apr
(7) |
May
(38) |
Jun
|
Jul
(7) |
Aug
|
Sep
(5) |
Oct
(10) |
Nov
(11) |
Dec
(1) |
| 2014 |
Jan
(16) |
Feb
(18) |
Mar
(11) |
Apr
(5) |
May
(13) |
Jun
(5) |
Jul
(5) |
Aug
(7) |
Sep
(30) |
Oct
|
Nov
|
Dec
(26) |
| 2015 |
Jan
(5) |
Feb
(19) |
Mar
(8) |
Apr
(15) |
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(16) |
Dec
(10) |
| 2016 |
Jan
|
Feb
(1) |
Mar
(14) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Hannes S. <ha...@yl...> - 2011-12-04 16:53:42
|
Both merged |
|
From: Hannes S. <ha...@yl...> - 2011-12-04 16:47:52
|
Merged |
|
From: Daniel C. <dan...@gm...> - 2011-12-02 20:22:35
|
Hi, for compatibility to vimperator I implemented the hinting also for images. With ;i images can be opened in curretn window and with ;I into a new one. Daniel |
|
From: Daniel C. <dan...@gm...> - 2011-12-02 20:15:47
|
Hi, I noticed, that the ;O and ;T hints doesn't work. Attaches patch fixes the bug. Daniel |
|
From: Daniel C. <dan...@gm...> - 2011-11-20 18:51:36
|
Hi! On Sun, Nov 20, 2011 at 04:43:21PM +0100, Hannes Schüller wrote: > The more I think about it, the more I believe *this* attached version > is the much more elegant solution. It disabled INSERT mode > automatically when the page *begins* to load rather than after loading > has finished. > > Can anyone think of any unintentional side-effects? For the first this solution seems to be better. I cant imagine a case where it may cause unintended side-effects. So, I'll install it and test it. Daniel |
|
From: Hannes S. <ha...@yl...> - 2011-11-20 15:44:08
|
The more I think about it, the more I believe *this* attached version is the much more elegant solution. It disabled INSERT mode automatically when the page *begins* to load rather than after loading has finished. Can anyone think of any unintentional side-effects? Hannes |
|
From: Daniel C. <dan...@gm...> - 2011-11-20 13:19:58
|
Hi! The error occours in the line where the proxy url is set. g_object_set(session, "proxy-uri", proxy_uri, NULL); But I think the error is somewhere in the glib or webkit. Daniel |
|
From: Hannes S. <ha...@yl...> - 2011-11-20 09:58:02
|
This patch is supposed to prevent the browser switching from INSERT to NORMAL mode after it has finished loading in case INSERT has only just been activated by the user. Steps to reproduce the problem: - Load a slow-loading website - When it is only partially loaded, click on an input field (INSERT should be activated) - Let the page load completely (INSERT is deactivated) After applying the patch, INSERT should be retained. Hannes |
|
From: Hannes S. <ha...@yl...> - 2011-11-19 11:23:20
|
Works for me. Anyone else? Hannes |
|
From: Daniel C. <dan...@gm...> - 2011-11-18 22:13:44
|
Hi! I switches to lates Ubuntu version 11.10 and now vimprobable sometimes segfaults (version of master branch). The segfault occours only if proxy is enabled and then only on some pages. I disables proxy and opened https://gist.github.com/950556, no segfault. I enabled proxy by :set proxy=true and reloded the page and the segfault occoured. If proxy is enabled I can't open these url. Other urls seems to work fine also https pages work. I have no idea what's wrong, maybe it a broken glib version from the upgraded ubuntu. Maybe someone else can have a look at this error. Daniel Here is the backtrace from gdb: ------------------------------- GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed Program received signal SIGTRAP, Trace/breakpoint trap. 0x01cb9d99 in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0 (gdb) bt full #0 0x01cb9d99 in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0 No symbol table info available. #1 0x01cba0d3 in g_log () from /lib/i386-linux-gnu/libglib-2.0.so.0 No symbol table info available. #2 0x01cba33d in g_return_if_fail_warning () from /lib/i386-linux-gnu/libglib-2.0.so.0 No symbol table info available. #3 0x01c2872b in g_object_ref () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 No symbol table info available. #4 0x01be90e5 in ?? () from /usr/lib/libsoup-2.4.so.1 No symbol table info available. #5 0x01beab98 in soup_message_io_client () from /usr/lib/libsoup-2.4.so.1 No symbol table info available. #6 0x01be7185 in soup_message_send_request () from /usr/lib/libsoup-2.4.so.1 No symbol table info available. #7 0x01bd8176 in soup_connection_send_request () from /usr/lib/libsoup-2.4.so.1 No symbol table info available. #8 0x01bf3f6e in soup_session_send_queue_item () from /usr/lib/libsoup-2.4.so.1 No symbol table info available. #9 0x01bf6d8b in ?? () from /usr/lib/libsoup-2.4.so.1 No symbol table info available. #10 0x01bf704f in ?? () from /usr/lib/libsoup-2.4.so.1 No symbol table info available. #11 0x01bf7858 in ?? () from /usr/lib/libsoup-2.4.so.1 No symbol table info available. #12 0x01cad110 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 No symbol table info available. #13 0x01cb125f in g_main_context_dispatch () from /lib/i386-linux-gnu/libglib-2.0.so.0 No symbol table info available. #14 0x01cb1990 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 No symbol table info available. #15 0x01cb1f9b in g_main_loop_run () from /lib/i386-linux-gnu/libglib-2.0.so.0 No symbol table info available. #16 0x0178dfcf in gtk_main () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0 No symbol table info available. #17 0x0805381f in main (argc=2, argv=0xbffff0d4) at main.c:2601 a = {i = 0, s = 0x80636e0 "https://gist.github.com/950556"} url = "https://gist.github.com/950556", '\000' <repeats 225 times> ver = 0 configfile_exists = 1 cfile = 0x0 searchengines_file = 0x84505b8 "\001" opts = {{long_name = 0x8058e6f "version", short_name = 118 'v', flags = 0, arg = G_OPTION_ARG_NONE, arg_data = 0x80636b8, description = 0x8058e77 "print version", arg_description = 0x0}, { long_name = 0x8058e85 "embed", short_name = 101 'e', flags = 0, arg = G_OPTION_ARG_STRING, arg_data = 0x8063298, description = 0x8058e8b "embedded", arg_description = 0x0}, {long_name = 0x8058e94 "configfile", short_name = 99 'c', flags = 0, arg = G_OPTION_ARG_STRING, arg_data = 0x80636bc, description = 0x8058e9f "config file", arg_description = 0x0}, {long_name = 0x0, short_name = 0 '\000', flags = 0, |
|
From: Hannes S. <ha...@yl...> - 2011-11-14 20:14:12
|
Hello Matt! Matt Carter <je...@gm...> wrote: > Easily fixed by changing the default in keymap.h prior to building, > but GDK_o and GDK_i are incorrectly mapped if you are looking to keep > consistent with Vimperator/Pentadactyl firefox add ons, or with > VI/VIM. > > ^o should be NavigationBack while ^i should go foward. This has been discussed a couple of times already. The consensus so far has been to rather have keybindings which make sense by default (i.e. "right" equals "forward" and "left" equals "backward") than to stay slavishly compatible. Overriding this in order to revert to Vim behaviour is as simple as you describe or (even simpler) including two map commands in vimprobablerc. Hannes |
|
From: Matt C. <je...@gm...> - 2011-11-14 19:12:28
|
Easily fixed by changing the default in keymap.h prior to building, but GDK_o and GDK_i are incorrectly mapped if you are looking to keep consistent with Vimperator/Pentadactyl firefox add ons, or with VI/VIM. ^o should be NavigationBack while ^i should go foward. |
|
From: Hannes S. <ha...@yl...> - 2011-11-13 16:14:24
|
This is a bugfix release: - Applying urlboxfont, urlboxcolor and urlboxbgcolor (Hut) - Cleaner way of protectiing the clipboard when focusing the inputbar (Hut) - Improved if-else-if logic in process_set_line() (Daniel Carl) - Yanking selected text (ticket #8) (Hannes Schüller) - Automatic INSERT mode through mouse clicks on input elements without Javascript (porti/Hannes Schüller) Some other patches have not been processed yet, because I need to verify them first. Wanted to get this release out due to the annoying yanking bug nevertheless. Hannes |
|
From: Hannes S. <ha...@yl...> - 2011-11-13 15:47:58
|
Applied |
|
From: Hannes S. <ha...@yl...> - 2011-11-13 15:45:12
|
Applied |
|
From: Hannes S. <ha...@yl...> - 2011-11-13 15:44:44
|
Applied |
|
From: Hannes S. <ha...@yl...> - 2011-11-13 15:38:03
|
Applied |
|
From: Hannes S. <ha...@yl...> - 2011-11-13 15:34:07
|
Applied |
|
From: Hannes S. <ha...@yl...> - 2011-11-13 15:32:54
|
Applied |
|
From: Hannes S. <ha...@yl...> - 2011-11-09 19:19:13
|
Hi! Daniel Carl <dan...@gm...> wrote: > I like the command history of vimprobable, also if I don't use it > very often. The feture I'd like to use more often would be a history > of last searches like the command history. > For me a solution that allows to use the history in defferent windows > would be prefered. I'm not really interested in that myself, but it would be quite easy to do, equivalent to the command history: When something has been identified as a search term (i.e. in open_arg), append that string to a status file. Retrieve the lines from that file when the command line contains an :open command and cursor up or down are used. Hannes |
|
From: Daniel C. <dan...@gm...> - 2011-11-09 01:32:20
|
Hi! I fixed a bug that the command pointer wasn't reseted after the command history search was interupted by ESC press. By the way I used GList to reimplemente command history feature, so we have 2 global vairables less than before. Daniel |
|
From: Daniel C. <dan...@gm...> - 2011-11-09 01:28:06
|
Hi! I like the command history of vimprobable, also if I don't use it very often. The feture I'd like to use more often would be a history of last searches like the command history. For me a solution that allows to use the history in defferent windows would be prefered. Daniel |
|
From: Daniel C. <dan...@gm...> - 2011-11-08 16:34:52
|
On Tue, Nov 08, 2011 at 12:25:37PM +0100, Hannes Schüller wrote:
> My rationale: PASSTHROUGH is always set manually, i.e. the user has
> specifically requested it. Dumping him back to normal mode would seem
> to go against the expectations ("I set PASSTHROUGH"). INSERT is usually
> handled automatically, so this should work in both directions
> (activation and deactivation).
>
> Hannes
This makes sense! I think we can do it in that way.
Daniel
|
|
From: Hannes S. <ha...@yl...> - 2011-11-08 11:27:19
|
Daniel Carl <dan...@gm...> wrote:
> Maybe the other users can post their opinions.
It *would* be nice, but it hardly ever happens.
My rationale: PASSTHROUGH is always set manually, i.e. the user has
specifically requested it. Dumping him back to normal mode would seem
to go against the expectations ("I set PASSTHROUGH"). INSERT is usually
handled automatically, so this should work in both directions
(activation and deactivation).
Hannes
|
|
From: Daniel C. <dan...@gm...> - 2011-11-08 08:11:37
|
On Mon, Nov 07, 2011 at 07:46:39PM +0100, Hannes Schüller wrote: > Sorry for the very short e-mail yesterday. This is what I'm proposing. > > Hannes It's OK, I knew what you mean, but I'm undecided if it's the right behaviour to leave only insert mode after page load. The patch works for me, because I had always troubles with insert mode that wasn't left after form post. But I'm not sure if it's good to keep in mode passthrough after loading a page. Maybe the other users can post their opinions. Daniel |
2 messages has been excluded from this view by a project administrator.
