vimprobable-users Mailing List for Vimprobable (Page 8)
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: Matthew C. <je...@gm...> - 2014-05-02 18:27:42
|
Hi all, Attached is a patch to do what Marcos described, it also lets you edit the source and upon saving and quitting your editor, it updates the page's source code to match what you changed. Uses the same logic and URI handler as the special textarea editor handling. It does not include the surrounding <html> tags or the doctype as that makes it difficult to refresh the browser with what was edited (so essentially you're getting a view of the document.documentElement.innerHTML, which you can then change/look through in your editor of choice). Thanks, -Matt On Sun, Apr 20, 2014 at 03:35:10PM +0200, Marcos Cruz wrote: > Hi all, > > Sometimes, when I need to examinate the source of a page, I prefer to do > it with all the power of Vim instead of the internal viewer. So I get > the page with wget or the Elinks browser and then launch Vim. > > I think currently there's no way to choose an external editor as source > viewer. Am I right? If so, I suggest this feature. Would it be > feasible? Do other Vimprobable users would find it useful? > > -- > Marcos Cruz > http://programandala.net > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/NeoTech > _______________________________________________ > Vimprobable-users mailing list > Vim...@li... > https://lists.sourceforge.net/lists/listinfo/vimprobable-users -- Matthew Carter je...@gm... |
|
From: Marcos C. <vim...@pr...> - 2014-04-20 16:33:07
|
Hi all, Sometimes, when I need to examinate the source of a page, I prefer to do it with all the power of Vim instead of the internal viewer. So I get the page with wget or the Elinks browser and then launch Vim. I think currently there's no way to choose an external editor as source viewer. Am I right? If so, I suggest this feature. Would it be feasible? Do other Vimprobable users would find it useful? -- Marcos Cruz http://programandala.net |
|
From: Matthew C. <je...@gm...> - 2014-04-04 18:00:20
|
Thanks Jason, that does the trick. -Matt On Fri, Apr 04, 2014 at 06:08:23PM +1300, Jason Ryan wrote: > On 03/04/14 at 04:58pm, Matthew Carter wrote: > > Hi all (long time no mail), > > > > I use the Shift + Insert keybind to paste my primary selection (whether > > selected text from urxvt or vimprobable2) and it pastes it perfectly > > back into the terminal, however Shift + Insert wants to insert the > > Clipboard contents on vimprobable2. > > > > On firefox with Pentadactyl, the shift+insert also inserts the primary > > selection (however on Chromium, the vimprobable2 behavior is present, > > Shift+Insert dropping in the clipboard contents). > > > > My laptop does not have a mouse or touchpad support to simulate mouse 3 > > clicks, so this is the main way I move text around applications. > > > > Is there a compilation time or other fix to make Shift+Insert default to > > pasting the primary selection? (or any other keybind I could use for > > it) > > > > I putzed around the webkit code a little bit for this, but could not > > find an answer. > > > > The closest solution I have so far is running something like: > > > > xsel -po|xsel -bi > > > > To copy the primary to the clipboard each time, but it seems a bit > > clunky. > > > I use autocutsel for this, and other similar situations: > http://www.nongnu.org/autocutsel/ > > Cheers, > > /J > > -- > > http://jasonwryan.com/ [GnuPG Key: B1BD4E40] > > > ------------------------------------------------------------------------------ > _______________________________________________ > Vimprobable-users mailing list > Vim...@li... > https://lists.sourceforge.net/lists/listinfo/vimprobable-users -- Matthew Carter je...@gm... |
|
From: Jason R. <jas...@gm...> - 2014-04-04 05:08:37
|
On 03/04/14 at 04:58pm, Matthew Carter wrote: > Hi all (long time no mail), > > I use the Shift + Insert keybind to paste my primary selection (whether > selected text from urxvt or vimprobable2) and it pastes it perfectly > back into the terminal, however Shift + Insert wants to insert the > Clipboard contents on vimprobable2. > > On firefox with Pentadactyl, the shift+insert also inserts the primary > selection (however on Chromium, the vimprobable2 behavior is present, > Shift+Insert dropping in the clipboard contents). > > My laptop does not have a mouse or touchpad support to simulate mouse 3 > clicks, so this is the main way I move text around applications. > > Is there a compilation time or other fix to make Shift+Insert default to > pasting the primary selection? (or any other keybind I could use for > it) > > I putzed around the webkit code a little bit for this, but could not > find an answer. > > The closest solution I have so far is running something like: > > xsel -po|xsel -bi > > To copy the primary to the clipboard each time, but it seems a bit > clunky. > I use autocutsel for this, and other similar situations: http://www.nongnu.org/autocutsel/ Cheers, /J -- http://jasonwryan.com/ [GnuPG Key: B1BD4E40] |
|
From: Roland D. <dob...@gm...> - 2014-04-04 04:34:18
|
On Thu, Apr 03, 2014 at 04:58:02PM -0400, Matthew Carter wrote: > Hi all (long time no mail), > > I use the Shift + Insert keybind to paste my primary selection (whether > selected text from urxvt or vimprobable2) and it pastes it perfectly > back into the terminal, however Shift + Insert wants to insert the > Clipboard contents on vimprobable2. > > On firefox with Pentadactyl, the shift+insert also inserts the primary > selection (however on Chromium, the vimprobable2 behavior is present, > Shift+Insert dropping in the clipboard contents). > > My laptop does not have a mouse or touchpad support to simulate mouse 3 > clicks, so this is the main way I move text around applications. > > Is there a compilation time or other fix to make Shift+Insert default to > pasting the primary selection? (or any other keybind I could use for > it) > > I putzed around the webkit code a little bit for this, but could not > find an answer. > > The closest solution I have so far is running something like: > > xsel -po|xsel -bi > > To copy the primary to the clipboard each time, but it seems a bit > clunky. > > Thanks, > -Matt > > -- > Matthew Carter > je...@gm... If you mean pasting an URL then "p" should work. At least it works for me. If you want to paste into a form then probably the best way to do it to use <CTRL-T>, open a terminal with an editor, and past it as you do it usually in other terminals. -- PGP key fingerprint: 5A40 3CCB 32A5 5CFB 270C 7A00 535C 512A AFB9 0500 |
|
From: Matthew C. <je...@gm...> - 2014-04-03 20:58:12
|
Hi all (long time no mail), I use the Shift + Insert keybind to paste my primary selection (whether selected text from urxvt or vimprobable2) and it pastes it perfectly back into the terminal, however Shift + Insert wants to insert the Clipboard contents on vimprobable2. On firefox with Pentadactyl, the shift+insert also inserts the primary selection (however on Chromium, the vimprobable2 behavior is present, Shift+Insert dropping in the clipboard contents). My laptop does not have a mouse or touchpad support to simulate mouse 3 clicks, so this is the main way I move text around applications. Is there a compilation time or other fix to make Shift+Insert default to pasting the primary selection? (or any other keybind I could use for it) I putzed around the webkit code a little bit for this, but could not find an answer. The closest solution I have so far is running something like: xsel -po|xsel -bi To copy the primary to the clipboard each time, but it seems a bit clunky. Thanks, -Matt -- Matthew Carter je...@gm... |
|
From: Karryanna <ka...@ka...> - 2014-03-30 10:55:25
|
Hello, I've run into another strange behavior. When I try to download some non-existent file from a specific page, say I try to get http://ufal.mff.cuni.cz/~mirovsky/vyuka/NPFL075/2014/data.zip Vimprobable reports 'Download data.zip finished', however the downloaded file is actually HTML containing error page. I suspect there's some error with the server as it doesn't happen to me elsewhere, and even Lynx seems to get confused but wget or Iceweasel can cope with that well. Is this in any way a bug in Vimprobable? Karry |
|
From: Daniel C. <dan...@gm...> - 2014-03-05 20:49:45
|
Daniel Carl Karryanna <ka...@ka...> wrote: > > I can reproduce it, this is a bug. The hinting script does not know how to > > handle the <input type="search"/>. There are a lot of input types allowed > > through [html5][]. At the moment the input mode is started for input type > > 'text', 'password', 'checkbox' and 'radio' (by the way, makes it no sense to > > switch to input mode if a radion button is hinted). > > OK, I'll hope for a fix then. The attached patch should fix the issue. I haven't tested this much, and restructured the hinting decision completely, so maybe some other hinting will be broken. The main change is that we switch to input mode for most input types and make some exceptions for input types that expect no input 'radio', 'checkbox', 'submit', 'reset', 'button' and 'image'. Maybe there will some of the new html5 input types that shouldn't force vimprobable into input mode too. Daniel |
|
From: Daniel C. <dan...@gm...> - 2014-03-05 20:21:22
|
Daniel Carl Karryanna <ka...@ka...> wrote: > > > • Searching terms with diacritics sometimes breaks the diacritics > > > Sometimes I try to search for a term including diacritics but when > > > I get results, it seems that the diacritics had been broken somewhere. > > > It should be reproducable for example here: > > > https://is.cuni.cz/studium/eng/kdojekdo/index.php?KEY=Az1 > > > Say you wish to search for person whose family name is "Burešová". > > > After searching, I see "BureÅ¡ová" in the field. > > > [...] > > > However, on many sites searching with diacritis works all right. > > > > > > Do you have any ideas about what this could be caused by? > > > > In general such issues are caused by different character encondings used for > > the page and the server side application. > > Still other browsers can cope with that. > Is there a chance someone would get into that and possibly come with a patch > or workaround? > Or could someone give me a hint about how to find out more? You are right, the search form is submitted via http GET and it seems the url is encoded by webkit in a wrong way. This behaviour appears in all webkitgtk based browser I've available here. If the search URI is typed into inputbox, the encoding is done right. If there is no setting to change the behaviour of webkit, I fear that we can't do much to prevent this behaviour. But I'll try to get into the issue. Daniel |
|
From: Karryanna <ka...@ka...> - 2014-03-05 10:36:50
|
> To add one minor point to Daniel's comprehensive reply: > > On 04/03/14 at 02:05pm, Karryanna wrote: > > > >• Perhaps not so important issue, is it possible that launching Vim > >to edit form fields is not documented? > >[...] > > > This is documented in the man page, Vimprobable2(1), under URI Handlers. OK. To be honest, I think it would be better to have it documented also at webpage so that anyone can read it before deciding to give or not to give Vimprobable a try. But I leave this to you. The other thing is I get "no manual entry" but I suppose this will be just a bug of my local installation, caused by me. I still prefer to get things installed via aptitude, therefore am in no way skilled in doing it manually and could have easily overlooked some dependencies or error. I think I'll try to reinstall Vimprobable really carefully and only call for help if this doesn't help. Karry |
|
From: Karryanna <ka...@ka...> - 2014-03-05 10:26:41
|
Hi Daniel, thank you for all the time and effort you put into this! > > • First of all, hinting sometimes doesn't work for me. > > The only case I can report is search field at PHP website, > > http://www.php.net > > [...] > > I can reproduce it, this is a bug. The hinting script does not know how to > handle the <input type="search"/>. There are a lot of input types allowed > through [html5][]. At the moment the input mode is started for input type > 'text', 'password', 'checkbox' and 'radio' (by the way, makes it no sense to > switch to input mode if a radion button is hinted). OK, I'll hope for a fix then. > > The other case I've noted down is webpage through which I sometimes submit > > my homeworks, where hint for file selection shows but following it doesn't > > really bring up the selection dialog. However, this site is login protected. > > Anyway, I'd like to note that if I select next form field, tab back and > > press enter, everything works as expected. > > > > Is there any explanation to this, and more importantly, some kind of a fix? > > That's hard to say without seeing the html code of the page. Well, since it's login protected and tabbing back from next field is still quiete comfortable, I'll let it be and only if I encounter this somewhere else, I'll report it again. > > • Searching terms with diacritics sometimes breaks the diacritics > > Sometimes I try to search for a term including diacritics but when > > I get results, it seems that the diacritics had been broken somewhere. > > It should be reproducable for example here: > > https://is.cuni.cz/studium/eng/kdojekdo/index.php?KEY=Az1 > > Say you wish to search for person whose family name is "Burešová". > > After searching, I see "BureÅ¡ová" in the field. > > [...] > > However, on many sites searching with diacritis works all right. > > > > Do you have any ideas about what this could be caused by? > > In general such issues are caused by different character encondings used for > the page and the server side application. Still other browsers can cope with that. Is there a chance someone would get into that and possibly come with a patch or workaround? Or could someone give me a hint about how to find out more? > > • Is it possible to download current page/file? > > [...] > > The was an path in the past that provided a :write or :save command to save > the current opened document. But this was never merged into vimprobable, don't > know why. A workaround could be the :print command that opens the print dialog > where you can print the page into pdf or ps, but this isn't the same I know. It's a pitty it wasn't merged. But thanks for mentioning, I'll try to search the archive and see if I could apply it anyway. > > • Is there any kind of hinting for frames? > > I know that frames are evil and stuff but anyway, for example > > http://srazy.hocz.org/index2.html > > is a page informing about meetings of a community I belonged in and it's > > made using frames. Is there a way to select the right frame so that for > > example j/k movement takes effect? (It's not needed at real index but it > > would come in handy after selecting some menu entry.) > > This hinting does not exist, an we hope frame will fade away from the www. To > implement the hinting wouldn't be too difficult, but the scrolling is done in > vimprobable on a scrollable window containing the webview. I don't have any > idea if there's a way to scroll within a defined frame without using > JavaScript (like dwb does). OK. I admit this is a kind of magic for me, I only remember that when I used to use Mouseless browsing in Firefox several years ago, I could select a frame and navigation in that frame then worked all right. If it's not that easy at all, I can get over it somehow. > Puh, that was a really long mail and it costs me a lot of time and attention. > I think for the next time it's better to split the mail into single issue. > These would be easier to answer and to keep track of unanswered issue and > questions. Sorry and once more thanks for the time you put in it. You know, the idea of sending like ten mails at once felt so stupid. Now I see it would had been better. Next time I'll split it. Or even better, I won't be so afraid of the community and will report issues before there's so much of them (though I guess it would be wise to wait for a few days and try to solve them myself first). Karry |
|
From: Jason R. <jas...@gm...> - 2014-03-04 23:10:26
|
To add one minor point to Daniel's comprehensive reply: On 04/03/14 at 02:05pm, Karryanna wrote: > >• Perhaps not so important issue, is it possible that launching Vim >to edit form fields is not documented? >I'd neved used Vimperator before I discovered Vimprobable so it just >didn't come to my mind that Vim could possibly be used. After I onced >launched it incidentally, it took me some time searching how it is >done and now I consider it one of greatest features which surely >should be documented. > This is documented in the man page, Vimprobable2(1), under URI Handlers. /J -- http://jasonwryan.com/ [GnuPG Key: B1BD4E40] |
|
From: Daniel C. <dan...@gm...> - 2014-03-04 23:03:32
|
Hi Karry! Karryanna <ka...@ka...> wrote: > • First of all, hinting sometimes doesn't work for me. > The only case I can report is search field at PHP website, > http://www.php.net > If I hit `f`, I get a number for that field, however following it doesn't > result in anything (visible). > No matter what I think about PHP and no matter in this particular case > I could use accesskey, I consider this a bug. I can reproduce it, this is a bug. The hinting script does not know how to handle the <input type="search"/>. There are a lot of input types allowed through [html5][]. At the moment the input mode is started for input type 'text', 'password', 'checkbox' and 'radio' (by the way, makes it no sense to switch to input mode if a radion button is hinted). > The other case I've noted down is webpage through which I sometimes submit > my homeworks, where hint for file selection shows but following it doesn't > really bring up the selection dialog. However, this site is login protected. > Anyway, I'd like to note that if I select next form field, tab back and > press enter, everything works as expected. > > Is there any explanation to this, and more importantly, some kind of a fix? That's hard to say without seeing the html code of the page. > • Another issue, downloaded files are sometimes saved under name `url`. > I suspect this happens with any Google search, and this surely happened > to me at some other websites. > Unfortunately, I haven't noted down any of those other sites and Google > attempts of personalised searches could make reproducing difficult, but > googling "kartografie" lists link to > http://www.google.com/url?q=http://gis.zcu.cz/studium/tka/Slides/uvod_do_kartografie.pdf > for me but following the link gets the file saved as `url`. This is a redirect page, and it seems that webkit uses only the part until the question mark to determine the download file name. Sound's like a webkit misbehaviour. > • To stay with downloading, how does renaming of downloaded files work? > I noticed that tar files get numbered. I mean, if `archive.tar` exists, > another file of that name gets saved as `archive.tar.1`, another as > `archive.tar.2` and so on. However, if for example `photo.jpg` exists, > and I try to download another file of that name, the old one is moved > to `photo.jpg~` and the new one gets saved under its name. Downloading > any other `photo.jpg` would get the very first file lost definitely. > Especially in combination with saving files as `url`, that's not nice. > So, what's the policy? And is it in any way configurable? Sound's strange, never noticed this behaviour. There isn't any logic for in vimprobable itself, so this must be a webkit feature. > • Searching terms with diacritics sometimes breaks the diacritics > Sometimes I try to search for a term including diacritics but when > I get results, it seems that the diacritics had been broken somewhere. > It should be reproducable for example here: > https://is.cuni.cz/studium/eng/kdojekdo/index.php?KEY=Az1 > Say you wish to search for person whose family name is "Burešová". > After searching, I see "BureÅ¡ová" in the field. > Another example is my highschool's site, http://www.gym-cl.cz > There's search field in the upper right corner, I used it for example > to search for "suplování" but after the search, it again seems to be > broken. > However, on many sites searching with diacritis works all right. > > Do you have any ideas about what this could be caused by? In general such issues are caused by different character encondings used for the page and the server side application. > • Is it possible to use different encoding to display page/file? > I got to think about that after trying to view > http://www.karryanna.cz/misc/dopis_nejen_jeziskovi.draft > using some browsers. As for this file, it turned out to be a little bit > more sophisticated problem, but anyway, could I force Vimprobable to > display a file using some specific encoding, say using UTF-8? Yes, :set defaultencoding=utf-8 and reloading of the page should do the trick. > • Is it possible to see link's location before following it? > I sometimes wish to know where a link leads before I really follow it. > I can get to know it by hovering over the link with my mouse but I wish > to do it using keyboard. > I currently use `;y` to achieve this but it's not exactly the same. > Is there something else? This feature does not exist. And there is no workaround for this. > • Is there any kind of private mode? > The thing I care about is history saving. I sometimes browse websites > whose addresses I don't like to show up in tab completion during, say, > practical session at university. > I could rename the history file and after I am done, rename it back > but I don't think this would be a nice solution. However, it surely is > one I can live with. There is no private mode available at the time. > • Is it possible to download current page/file? > Say I would have > http://www.karryanna.cz/misc/dopis_nejen_jeziskovi.draft > mentioned above opened in Vimprobable. Can I get it to save that file? > Like, without going to parent directory and using `;s` (or making > direct link from special page). The was an path in the past that provided a :write or :save command to save the current opened document. But this was never merged into vimprobable, don't know why. A workaround could be the :print command that opens the print dialog where you can print the page into pdf or ps, but this isn't the same I know. > • Is there any kind of hinting for frames? > I know that frames are evil and stuff but anyway, for example > http://srazy.hocz.org/index2.html > is a page informing about meetings of a community I belonged in and it's > made using frames. Is there a way to select the right frame so that for > example j/k movement takes effect? (It's not needed at real index but it > would come in handy after selecting some menu entry.) This hinting does not exist, an we hope frame will fade away from the www. To implement the hinting wouldn't be too difficult, but the scrolling is done in vimprobable on a scrollable window containing the webview. I don't have any idea if there's a way to scroll within a defined frame without using JavaScript (like dwb does). > • Sometimes I can't leave insert mode > I am not sure whether I should report this since I can't reproduce it. > However, sometimes I get stuck in insert mode, it seems that pressing > escape leads to leaving it and activating it again immediately. The only > way to leave the mode is to tab outside of the form and use escape there. > > Has anyone else encountered this? Normally you should be able to avoid this by setting escapeinput=true. > Well, that's finally all for now. > I'll be greatful for any suggestions and help (as well as for patience > with me). Puh, that was a really long mail and it costs me a lot of time and attention. I think for the next time it's better to split the mail into single issue. These would be easier to answer and to keep track of unanswered issue and questions. Daniel [html5]: http://sixrevisions.com/html5/new-html5-form-input-types/ |
|
From: Karryanna <ka...@ka...> - 2014-03-04 13:22:39
|
Hello everyone, I feel terribly lame writing this e-mail so first of all, I am sorry if I am doing anything about it wrong. To make it worse, I've collected quite a lot of issues :) Even though I have hunted some of them down to be my mistakes or misunderstandings, a lot of them remained to be reported. • First of all, hinting sometimes doesn't work for me. The only case I can report is search field at PHP website, http://www.php.net If I hit `f`, I get a number for that field, however following it doesn't result in anything (visible). No matter what I think about PHP and no matter in this particular case I could use accesskey, I consider this a bug. The other case I've noted down is webpage through which I sometimes submit my homeworks, where hint for file selection shows but following it doesn't really bring up the selection dialog. However, this site is login protected. Anyway, I'd like to note that if I select next form field, tab back and press enter, everything works as expected. Is there any explanation to this, and more importantly, some kind of a fix? • Another issue, downloaded files are sometimes saved under name `url`. I suspect this happens with any Google search, and this surely happened to me at some other websites. Unfortunately, I haven't noted down any of those other sites and Google attempts of personalised searches could make reproducing difficult, but googling "kartografie" lists link to http://www.google.com/url?q=http://gis.zcu.cz/studium/tka/Slides/uvod_do_kartografie.pdf for me but following the link gets the file saved as `url`. • To stay with downloading, how does renaming of downloaded files work? I noticed that tar files get numbered. I mean, if `archive.tar` exists, another file of that name gets saved as `archive.tar.1`, another as `archive.tar.2` and so on. However, if for example `photo.jpg` exists, and I try to download another file of that name, the old one is moved to `photo.jpg~` and the new one gets saved under its name. Downloading any other `photo.jpg` would get the very first file lost definitely. Especially in combination with saving files as `url`, that's not nice. So, what's the policy? And is it in any way configurable? • Perhaps not so important issue, is it possible that launching Vim to edit form fields is not documented? I'd neved used Vimperator before I discovered Vimprobable so it just didn't come to my mind that Vim could possibly be used. After I onced launched it incidentally, it took me some time searching how it is done and now I consider it one of greatest features which surely should be documented. • Searching terms with diacritics sometimes breaks the diacritics Sometimes I try to search for a term including diacritics but when I get results, it seems that the diacritics had been broken somewhere. It should be reproducable for example here: https://is.cuni.cz/studium/eng/kdojekdo/index.php?KEY=Az1 Say you wish to search for person whose family name is "Burešová". After searching, I see "BureÅ¡ová" in the field. Another example is my highschool's site, http://www.gym-cl.cz There's search field in the upper right corner, I used it for example to search for "suplování" but after the search, it again seems to be broken. However, on many sites searching with diacritis works all right. Do you have any ideas about what this could be caused by? • Javascript sometimes doesn't work? I am not really sure about the point of this issue. I get it when searching for some transport connection. If you go to http://jizdnirady.idnes.cz/autobusy/spojeni/ and fill for example "Odkud" as "Praha" and "Kam" as "Liberec" (not the one I would really search but one that anyone should be able to type :) ) and then press "Hledat", you should be presented with three bus connections. Above and below, there should be also arrows labeled as "Předchozí" and "Následující". Clicking them in other browsers results in showing three more connections, going before/after those presented. However, selecting them in Vimprobable does nothing (no matter whether I use hinting, accesskeys or mouse). Is this rather Vimprobable bug, JavaScript bug or some weird bug at this specific site? And again, could you think of any workaround? • Is it possible to use different encoding to display page/file? I got to think about that after trying to view http://www.karryanna.cz/misc/dopis_nejen_jeziskovi.draft using some browsers. As for this file, it turned out to be a little bit more sophisticated problem, but anyway, could I force Vimprobable to display a file using some specific encoding, say using UTF-8? • Is it possible to see link's location before following it? I sometimes wish to know where a link leads before I really follow it. I can get to know it by hovering over the link with my mouse but I wish to do it using keyboard. I currently use `;y` to achieve this but it's not exactly the same. Is there something else? • Is there any kind of private mode? The thing I care about is history saving. I sometimes browse websites whose addresses I don't like to show up in tab completion during, say, practical session at university. I could rename the history file and after I am done, rename it back but I don't think this would be a nice solution. However, it surely is one I can live with. • Is it possible to download current page/file? Say I would have http://www.karryanna.cz/misc/dopis_nejen_jeziskovi.draft mentioned above opened in Vimprobable. Can I get it to save that file? Like, without going to parent directory and using `;s` (or making direct link from special page). • Is there any kind of hinting for frames? I know that frames are evil and stuff but anyway, for example http://srazy.hocz.org/index2.html is a page informing about meetings of a community I belonged in and it's made using frames. Is there a way to select the right frame so that for example j/k movement takes effect? (It's not needed at real index but it would come in handy after selecting some menu entry.) • Sometimes I can't leave insert mode I am not sure whether I should report this since I can't reproduce it. However, sometimes I get stuck in insert mode, it seems that pressing escape leads to leaving it and activating it again immediately. The only way to leave the mode is to tab outside of the form and use escape there. Has anyone else encountered this? Well, that's finally all for now. I'll be greatful for any suggestions and help (as well as for patience with me). Karry |
|
From: Daniel C. <dan...@gm...> - 2014-03-03 21:55:32
|
Hannes Schüller <ha...@yl...> wrote: > Thanks, Daniel, for this detailed test campaign! What could work, in > principle, and the reason why I tried this incomplete mini-patch, would > be reverting part of the link firing logic to what we used back before > you rewrote this part. Not touching the main part, of course, as that > all works great. Just the following: > > Extend _openNewWindow (hinting.js) to determine what kind of hinted > element it is. > - If there is some onclick event or similar, generate the mouse click > as right now. The target attribute would not do anything anyway in > this case, so F behaves like f. > - If it's a regular link, return "tabopen;URL". The logic to handle > this is still in the script function in main.c, so it would work. > > I acknowledge and appreciate that this would be much less elegant than > the current implementation as it relies on specific, positive tests > instead of generic, timeless solutions, but if we consider all possible > options (hinting modes), it should work. > > Do you see any issues? Unfortunately, yes! 1. In case the is some onclick attribute set on the element, and the user used 'F' to open it, this would still be opened into the current window (if it opens a page). I think there are a lot of examples in the wild where the onclick does some tracking and than loads the requested page. Also the ixquick links have the onclick attribute set and call in fact window.open() deep in the JavaScript logic. 2. Onclick event handler can be defined outside of the element itself, and this is a common practice (http://api.jquery.com/bind/). I don't understand JavaScript as much, but I'm not sure if will see the bound event handlers of an element. For some cases where the event handler is set like following we can check 'e.onclick', but 'e.hasAttribute("onclick")' will return false. var Button = { click: function(){ alert("clicked"); } }; var e = document.createElement("div"); e.innerHTML = "Click me"; e.onclick = Button.click; e.hasAttribute('onclick')) // returns false ...several minutes later.. I got it, I hope. If the WebkitSetting "javascript-can-open-windows-automatically" is enabled, our current logic works. Maybe we can set this, depending on webkit version, or make it configurable for the user. http://webkitgtk.org/reference/webkit2gtk/unstable/WebKitSettings.html#WebKitSettings--javascript-can-open-windows-automatically |
|
From: Hannes S. <ha...@yl...> - 2014-03-03 18:15:25
|
Hi! On Sun, 2 Mar 2014 21:30:37 +0100, Daniel Carl <dan...@gm...> wrote: > Hannes Schüller <ha...@yl...> wrote: > > since this troubling effect turned up on IRC again, I'd like to try > > and dig a little deeper still. Of course, the issue is still that I > > can't reproduce the behaviour myself. To identify a possible cause, > > I made a small patch (attached). It would be great if anyone who > > experienced the issue of the non-working F in the past could try it > > out. > > I started to inspect the issue on webkitgtk 2.2.5. > [...] > I'm out of ideas how we can fire the click event to open the link > into a new window. Or how we can click the element in a way that the > 'notify_event_cb' is triggered. Thanks, Daniel, for this detailed test campaign! What could work, in principle, and the reason why I tried this incomplete mini-patch, would be reverting part of the link firing logic to what we used back before you rewrote this part. Not touching the main part, of course, as that all works great. Just the following: Extend _openNewWindow (hinting.js) to determine what kind of hinted element it is. - If there is some onclick event or similar, generate the mouse click as right now. The target attribute would not do anything anyway in this case, so F behaves like f. - If it's a regular link, return "tabopen;URL". The logic to handle this is still in the script function in main.c, so it would work. I acknowledge and appreciate that this would be much less elegant than the current implementation as it relies on specific, positive tests instead of generic, timeless solutions, but if we consider all possible options (hinting modes), it should work. Do you see any issues? Hannes |
|
From: Daniel C. <dan...@gm...> - 2014-03-02 20:30:29
|
Hi Hannes! Hannes Schüller <ha...@yl...> wrote: > Hi, > > since this troubling effect turned up on IRC again, I'd like to try and > dig a little deeper still. Of course, the issue is still that I can't > reproduce the behaviour myself. To identify a possible cause, I made a > small patch (attached). It would be great if anyone who experienced the > issue of the non-working F in the past could try it out. I started to inspect the issue on webkitgtk 2.2.5. To get into the issue I created a little local page with some links, with target attribute set to "_blank", "foo" and links without target attribute. To eliminate false negatives I remove the code that set or removes the target attribute in the hinting.js. So it does not matter if the hinting is started by 'f' or 'F', both should dispatch the click event on the hinted element. If the link contains a 'target' attribute, the click event fails or does not open the link. This is independent from the target attribute value, as long as the attributes value is not empty (target="" works for me, but target="foo" not). This seems to be the problem, because we set the target="_blank" to force webkit to open the link into a new window. I tried to replace the target attribute setting in hinting.js and to achieve the behaviour on an other way, but nothing worked. Setting the CTRL-Key flag on the event to simulate Ctrl-Mouse-Button-1 does not work, set the mouse button to 1 (Middle-Mouse-Button) does not open the link into new window. I'm out of ideas how we can fire the click event to open the link into a new window. Or how we can click the element in a way that the 'notify_event_cb' is triggered. Daniel |
|
From: Jason R. <jas...@gm...> - 2014-02-25 19:54:32
|
On 25/02/14 at 06:41pm, Hannes Schüller wrote: >Hi, > >since this troubling effect turned up on IRC again, I'd like to try and >dig a little deeper still. Of course, the issue is still that I can't >reproduce the behaviour myself. To identify a possible cause, I made a >small patch (attached). It would be great if anyone who experienced the >issue of the non-working F in the past could try it out. > Thanks Hannes, This fixes it for webkitgtk2 2.2.5. Cheers, /J -- http://jasonwryan.com/ [GnuPG Key: B1BD4E40] |
|
From: Serge E. H. <se...@ha...> - 2014-02-25 17:53:57
|
Quoting Hannes Schüller (ha...@yl...):
> Hi,
>
> since this troubling effect turned up on IRC again, I'd like to try and
> dig a little deeper still. Of course, the issue is still that I can't
> reproduce the behaviour myself. To identify a possible cause, I made a
> small patch (attached). It would be great if anyone who experienced the
> issue of the non-working F in the past could try it out.
>
> Warning: This is not supposed to be a serious patch for production
> environments! It will break other things, like links controlled
> primarily through Javascript. This is only for testing purposes!
>
> Hannes
> diff --git a/hinting.js b/hinting.js
> index 4997cae..58e682a 100644
> --- a/hinting.js
> +++ b/hinting.js
> @@ -386,11 +386,12 @@ function Hints() {
> var oldTarget = elem.target;
>
> /* set target to open in new window */
> - elem.target = "_blank";
> + /*elem.target = "_blank";
> _clickElement(elem);
> elem.target = oldTarget;
>
> - return "done;";
> + return "done;";*/
> + return "tabopen;" + elem.href;
> }
>
> /* fire moudedown and click event on given element */
Yup, with this change F works.
|
|
From: Hannes S. <ha...@yl...> - 2014-02-25 17:42:06
|
Hi, since this troubling effect turned up on IRC again, I'd like to try and dig a little deeper still. Of course, the issue is still that I can't reproduce the behaviour myself. To identify a possible cause, I made a small patch (attached). It would be great if anyone who experienced the issue of the non-working F in the past could try it out. Warning: This is not supposed to be a serious patch for production environments! It will break other things, like links controlled primarily through Javascript. This is only for testing purposes! Hannes |
|
From: Thorsten K. <tho...@gm...> - 2014-02-11 23:07:37
|
On Tue, Feb 11, 2014 at 10:45:39PM +0100, Serge E. Hallyn wrote: > Quoting Thorsten Köhne (tho...@gm...): > > On Mon, Feb 10, 2014 at 09:30:32PM +0100, Serge E. Hallyn wrote: > > > Quoting Hannes Schüller (ha...@yl...): > > > > Hi, > > > > > > > > no amount of testing enables me to reproduce this issue. Given that it > > > > seems to occur in other browsers built against the same libraries as > > > > well, I would assume that it's an issue in one of said libs rather than > > > > one of the browser. Though please speak up if anyone reading this can > > > > confirm this issue, too! > > > > > > Agreed. Thorsten, which version of webkit are you using? I appear to > > > be on libwebkit-dev 2.3.4-1ubuntu2. > > > > > > > I'm on 2.2.4-1. ArchLinux uses exactly the same version. And so it does > > with libsoup-dev (2.44.2-1) and gcc (4.8.2-2). > > I briefly tried to dig deeper last night, but it appears to come down > to a bug in whatever is interpreting the js (or perhaps in the rather > magic _clickElement()). > > -serge > Well that's far beyond of my coding abilities :-) I decided to go the easy way, back on Arch now... But anyway, thanks to both of you for your help! Thorsten |
|
From: Serge E. H. <se...@ha...> - 2014-02-11 21:45:47
|
Quoting Thorsten Köhne (tho...@gm...): > On Mon, Feb 10, 2014 at 09:30:32PM +0100, Serge E. Hallyn wrote: > > Quoting Hannes Schüller (ha...@yl...): > > > Hi, > > > > > > no amount of testing enables me to reproduce this issue. Given that it > > > seems to occur in other browsers built against the same libraries as > > > well, I would assume that it's an issue in one of said libs rather than > > > one of the browser. Though please speak up if anyone reading this can > > > confirm this issue, too! > > > > Agreed. Thorsten, which version of webkit are you using? I appear to > > be on libwebkit-dev 2.3.4-1ubuntu2. > > > > I'm on 2.2.4-1. ArchLinux uses exactly the same version. And so it does > with libsoup-dev (2.44.2-1) and gcc (4.8.2-2). I briefly tried to dig deeper last night, but it appears to come down to a bug in whatever is interpreting the js (or perhaps in the rather magic _clickElement()). -serge |
|
From: Thorsten K. <tho...@gm...> - 2014-02-10 20:51:12
|
On Mon, Feb 10, 2014 at 09:30:32PM +0100, Serge E. Hallyn wrote: > Quoting Hannes Schüller (ha...@yl...): > > Hi, > > > > no amount of testing enables me to reproduce this issue. Given that it > > seems to occur in other browsers built against the same libraries as > > well, I would assume that it's an issue in one of said libs rather than > > one of the browser. Though please speak up if anyone reading this can > > confirm this issue, too! > > Agreed. Thorsten, which version of webkit are you using? I appear to > be on libwebkit-dev 2.3.4-1ubuntu2. > I'm on 2.2.4-1. ArchLinux uses exactly the same version. And so it does with libsoup-dev (2.44.2-1) and gcc (4.8.2-2). |
|
From: Serge E. H. <se...@ha...> - 2014-02-10 20:30:39
|
Quoting Hannes Schüller (ha...@yl...): > Hi, > > no amount of testing enables me to reproduce this issue. Given that it > seems to occur in other browsers built against the same libraries as > well, I would assume that it's an issue in one of said libs rather than > one of the browser. Though please speak up if anyone reading this can > confirm this issue, too! Agreed. Thorsten, which version of webkit are you using? I appear to be on libwebkit-dev 2.3.4-1ubuntu2. |
|
From: Hannes S. <ha...@yl...> - 2014-02-10 20:17:03
|
Hi, no amount of testing enables me to reproduce this issue. Given that it seems to occur in other browsers built against the same libraries as well, I would assume that it's an issue in one of said libs rather than one of the browser. Though please speak up if anyone reading this can confirm this issue, too! Hannes |
2 messages has been excluded from this view by a project administrator.
