vimprobable-users Mailing List for Vimprobable (Page 3)
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: Jason R. <jas...@gm...> - 2015-04-21 20:55:23
|
On 21/04/15 at 09:49pm, hey hey wrote: >Hi, > >The "F" keybinding does not work, although all others keybindings works. > >I didn't touch the configuration files, I just did "make". > >If you've an idea... > There were several responses to your previous (identical) email: did you read any of them before reposting? /J -- http://jasonwryan.com/ GPG: 7817 E3FF 578E EEE1 9F64 D40C 445E 52EA B1BD 4E40 |
|
From: hey h. <cg...@gm...> - 2015-04-21 20:49:21
|
Hi, The "F" keybinding does not work, although all others keybindings works. I didn't touch the configuration files, I just did "make". If you've an idea... Thanks, Cyd |
|
From: Hannes S. <ha...@yl...> - 2015-04-21 19:54:29
|
Hello list, the attached patch fixes the segmentation fault of the originalwindow occuring under recent versions of libwebkit when a link is requested to be opened in a new window using the mouse. Testing appreciated! Hannes |
|
From: Daniel C. <dan...@gm...> - 2015-04-18 22:10:22
|
Daniel Carl Jason Ryan <jas...@gm...> wrote: > This has been around for a while; this small patch for hinting.js will fix > it. An unfortunate side-effect seems to be that it will > crash the original window when you use the mouse to "open in new tab"; > I don't use the mouse so it doesn't bother me, but caveat emptor etc… > > /J > > > @@ -395,11 +403,12 @@ > 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; > } This patch does only work for normal links if the hinted element uses onclick or something similar this would not work. I see often pages with links like '<a href="#" onclick="doFancyThings(); return false">' and sometimes this are not even liks but span-Elements. Daniel |
|
From: Jason R. <jas...@gm...> - 2015-04-17 20:19:29
|
On 17/04/15 at 05:16pm, cg...@gm... wrote:
>Hello,
>
>The "F" keybinding doesn't work, although the "t" works.
>
This has been around for a while; this small patch for hinting.js
will fix it. An unfortunate side-effect seems to be that it will
crash the original window when you use the mouse to "open in new tab";
I don't use the mouse so it doesn't bother me, but caveat emptor etc…
/J
@@ -395,11 +403,12 @@
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;
}
--
http://jasonwryan.com/
GPG: 7817 E3FF 578E EEE1 9F64 D40C 445E 52EA B1BD 4E40
|
|
From: Serge E. H. <se...@ha...> - 2015-04-17 18:08:51
|
On Fri, Apr 17, 2015 at 05:16:26PM +0100, cg...@gm... wrote: > Hello, > > The "F" keybinding doesn't work, although the "t" works. > > I didn't touch the configuration files, and did just "make". > > The error seems to be "Blocked a frame with origin [...] Protocols, domains, > and ports must match." > > Thank you for your help! Did you enable popups? My vimprobablerc has map <C-u>=:set popups=true and then I hit C-u before F (if that's what i want). |
|
From: Hannes S. <ha...@yl...> - 2015-04-17 18:08:14
|
Hi CydGy! On Fri, 17 Apr 2015 17:16:26 +0100, cg...@gm... wrote: > The "F" keybinding doesn't work, although the "t" works. Did you download the latest release snapshot or the Git master? > The error seems to be "Blocked a frame with origin [...] Protocols, > domains, and ports must match." This is unrelated, but rather refers to an issue of recursing hints into frames. Hannes |
|
From: <cg...@gm...> - 2015-04-17 16:16:40
|
Hello, The "F" keybinding doesn't work, although the "t" works. I didn't touch the configuration files, and did just "make". The error seems to be "Blocked a frame with origin [...] Protocols, domains, and ports must match." Thank you for your help! CydGy |
|
From: Serge E. H. <se...@ha...> - 2015-03-19 04:32:49
|
On Wed, Mar 18, 2015 at 04:21:00PM -0500, Serge E. Hallyn wrote:
> On Wed, Mar 18, 2015 at 04:03:48PM -0500, Serge E. Hallyn wrote:
> > On Wed, Mar 18, 2015 at 07:36:45PM +0100, Hannes Schüller wrote:
> > > Hi Serge!
> > >
> > > On Wed, 18 Mar 2015 13:13:11 -0500, "Serge E. Hallyn"
> > > <se...@ha...> wrote:
> > > > I don't believe what's going on is vimprobable's fault, but I don't
> > > > know how to investigate further. I assume it's a webkit problem...
> > > >
> > > > I upgraded my laptop from Ubuntu utopic to Ubuntu vivid - this did
> > > > not involve an upgrade of vimprobable2. But since I upgraded, I have
> > > > to login every time I start a new vimprobable. stracing suggests
> > > > that it is having no problem opening my cookies file. After logging
> > > > in I can use the page just fine, but a new vimprobable has to log
> > > > back in.
> > >
> > > It's very likely that you didn't create the cookies file (which you
> > > need to do by hand).
> >
> > No, I do have a cookies file, and strace shows that it is being
> > opened during a vimprobable run. (I first wondered whether there
> > might have been a change where the cookies file is supposed to
> > be, some xdg change or something)
>
> Hm, I just tried with another webkit browser (surf) and it does
> log me back in... so it's not webkit itself, likely. Weird.
>
> My cookies file for vimprobable has all the same cookies that the one
> surf generated had.
>
I've bisected libsoup, and the first bad commit is
commit 29a976932f1e991794f9c1efe8c346328902fc68
Author: Carlos Garcia Campos <cg...@ig...>
Date: Wed Feb 18 14:38:09 2015 +0100
Add SoupMessage::starting signal
|
|
From: Serge E. H. <se...@ha...> - 2015-03-18 22:24:13
|
On Wed, Mar 18, 2015 at 11:17:51PM +0100, Hannes Schüller wrote: > On Wed, 18 Mar 2015 17:13:37 -0500, "Serge E. Hallyn" > <se...@ha...> wrote: > > On Wed, Mar 18, 2015 at 04:21:00PM -0500, Serge E. Hallyn wrote: > > > On Wed, Mar 18, 2015 at 04:03:48PM -0500, Serge E. Hallyn wrote: > > > > On Wed, Mar 18, 2015 at 07:36:45PM +0100, Hannes Schüller wrote: > > > > > Hi Serge! > > > > > > > > > > On Wed, 18 Mar 2015 13:13:11 -0500, "Serge E. Hallyn" > > > > > <se...@ha...> wrote: > > > > > > I don't believe what's going on is vimprobable's fault, but I > > > > > > don't know how to investigate further. I assume it's a > > > > > > webkit problem... > > > > > > > > > > > > I upgraded my laptop from Ubuntu utopic to Ubuntu vivid - > > > > > > this did not involve an upgrade of vimprobable2. But since I > > > > > > upgraded, I have to login every time I start a new > > > > > > vimprobable. stracing suggests that it is having no problem > > > > > > opening my cookies file. After logging in I can use the page > > > > > > just fine, but a new vimprobable has to log back in. > > > > > > > > > > It's very likely that you didn't create the cookies file (which > > > > > you need to do by hand). > > > > > > > > No, I do have a cookies file, and strace shows that it is being > > > > opened during a vimprobable run. (I first wondered whether there > > > > might have been a change where the cookies file is supposed to > > > > be, some xdg change or something) > > > > > > Hm, I just tried with another webkit browser (surf) and it does > > > log me back in... so it's not webkit itself, likely. Weird. > > > > > > My cookies file for vimprobable has all the same cookies that the > > > one surf generated had. > > > > Ok it's libsoup - downgrading from 2.49.91.1-1 to 2.46.0-3 fixed it > > for me. > > Would rebuilding against this newer library help? Sadly no, I did a rebuild yesterday and it didn't help. I'll look through the changelog in a bit. |
|
From: Hannes S. <ha...@yl...> - 2015-03-18 22:18:17
|
On Wed, 18 Mar 2015 17:13:37 -0500, "Serge E. Hallyn" <se...@ha...> wrote: > On Wed, Mar 18, 2015 at 04:21:00PM -0500, Serge E. Hallyn wrote: > > On Wed, Mar 18, 2015 at 04:03:48PM -0500, Serge E. Hallyn wrote: > > > On Wed, Mar 18, 2015 at 07:36:45PM +0100, Hannes Schüller wrote: > > > > Hi Serge! > > > > > > > > On Wed, 18 Mar 2015 13:13:11 -0500, "Serge E. Hallyn" > > > > <se...@ha...> wrote: > > > > > I don't believe what's going on is vimprobable's fault, but I > > > > > don't know how to investigate further. I assume it's a > > > > > webkit problem... > > > > > > > > > > I upgraded my laptop from Ubuntu utopic to Ubuntu vivid - > > > > > this did not involve an upgrade of vimprobable2. But since I > > > > > upgraded, I have to login every time I start a new > > > > > vimprobable. stracing suggests that it is having no problem > > > > > opening my cookies file. After logging in I can use the page > > > > > just fine, but a new vimprobable has to log back in. > > > > > > > > It's very likely that you didn't create the cookies file (which > > > > you need to do by hand). > > > > > > No, I do have a cookies file, and strace shows that it is being > > > opened during a vimprobable run. (I first wondered whether there > > > might have been a change where the cookies file is supposed to > > > be, some xdg change or something) > > > > Hm, I just tried with another webkit browser (surf) and it does > > log me back in... so it's not webkit itself, likely. Weird. > > > > My cookies file for vimprobable has all the same cookies that the > > one surf generated had. > > Ok it's libsoup - downgrading from 2.49.91.1-1 to 2.46.0-3 fixed it > for me. Would rebuilding against this newer library help? Hannes |
|
From: Serge E. H. <se...@ha...> - 2015-03-18 22:13:45
|
On Wed, Mar 18, 2015 at 04:21:00PM -0500, Serge E. Hallyn wrote: > On Wed, Mar 18, 2015 at 04:03:48PM -0500, Serge E. Hallyn wrote: > > On Wed, Mar 18, 2015 at 07:36:45PM +0100, Hannes Schüller wrote: > > > Hi Serge! > > > > > > On Wed, 18 Mar 2015 13:13:11 -0500, "Serge E. Hallyn" > > > <se...@ha...> wrote: > > > > I don't believe what's going on is vimprobable's fault, but I don't > > > > know how to investigate further. I assume it's a webkit problem... > > > > > > > > I upgraded my laptop from Ubuntu utopic to Ubuntu vivid - this did > > > > not involve an upgrade of vimprobable2. But since I upgraded, I have > > > > to login every time I start a new vimprobable. stracing suggests > > > > that it is having no problem opening my cookies file. After logging > > > > in I can use the page just fine, but a new vimprobable has to log > > > > back in. > > > > > > It's very likely that you didn't create the cookies file (which you > > > need to do by hand). > > > > No, I do have a cookies file, and strace shows that it is being > > opened during a vimprobable run. (I first wondered whether there > > might have been a change where the cookies file is supposed to > > be, some xdg change or something) > > Hm, I just tried with another webkit browser (surf) and it does > log me back in... so it's not webkit itself, likely. Weird. > > My cookies file for vimprobable has all the same cookies that the one > surf generated had. Ok it's libsoup - downgrading from 2.49.91.1-1 to 2.46.0-3 fixed it for me. |
|
From: Serge E. H. <se...@ha...> - 2015-03-18 21:21:08
|
On Wed, Mar 18, 2015 at 04:03:48PM -0500, Serge E. Hallyn wrote: > On Wed, Mar 18, 2015 at 07:36:45PM +0100, Hannes Schüller wrote: > > Hi Serge! > > > > On Wed, 18 Mar 2015 13:13:11 -0500, "Serge E. Hallyn" > > <se...@ha...> wrote: > > > I don't believe what's going on is vimprobable's fault, but I don't > > > know how to investigate further. I assume it's a webkit problem... > > > > > > I upgraded my laptop from Ubuntu utopic to Ubuntu vivid - this did > > > not involve an upgrade of vimprobable2. But since I upgraded, I have > > > to login every time I start a new vimprobable. stracing suggests > > > that it is having no problem opening my cookies file. After logging > > > in I can use the page just fine, but a new vimprobable has to log > > > back in. > > > > It's very likely that you didn't create the cookies file (which you > > need to do by hand). > > No, I do have a cookies file, and strace shows that it is being > opened during a vimprobable run. (I first wondered whether there > might have been a change where the cookies file is supposed to > be, some xdg change or something) Hm, I just tried with another webkit browser (surf) and it does log me back in... so it's not webkit itself, likely. Weird. My cookies file for vimprobable has all the same cookies that the one surf generated had. |
|
From: Serge E. H. <se...@ha...> - 2015-03-18 21:03:56
|
On Wed, Mar 18, 2015 at 07:36:45PM +0100, Hannes Schüller wrote: > Hi Serge! > > On Wed, 18 Mar 2015 13:13:11 -0500, "Serge E. Hallyn" > <se...@ha...> wrote: > > I don't believe what's going on is vimprobable's fault, but I don't > > know how to investigate further. I assume it's a webkit problem... > > > > I upgraded my laptop from Ubuntu utopic to Ubuntu vivid - this did > > not involve an upgrade of vimprobable2. But since I upgraded, I have > > to login every time I start a new vimprobable. stracing suggests > > that it is having no problem opening my cookies file. After logging > > in I can use the page just fine, but a new vimprobable has to log > > back in. > > It's very likely that you didn't create the cookies file (which you > need to do by hand). No, I do have a cookies file, and strace shows that it is being opened during a vimprobable run. (I first wondered whether there might have been a change where the cookies file is supposed to be, some xdg change or something) thanks, -serge |
|
From: Hannes S. <ha...@yl...> - 2015-03-18 18:36:59
|
Hi Serge! On Wed, 18 Mar 2015 13:13:11 -0500, "Serge E. Hallyn" <se...@ha...> wrote: > I don't believe what's going on is vimprobable's fault, but I don't > know how to investigate further. I assume it's a webkit problem... > > I upgraded my laptop from Ubuntu utopic to Ubuntu vivid - this did > not involve an upgrade of vimprobable2. But since I upgraded, I have > to login every time I start a new vimprobable. stracing suggests > that it is having no problem opening my cookies file. After logging > in I can use the page just fine, but a new vimprobable has to log > back in. It's very likely that you didn't create the cookies file (which you need to do by hand). Hannes |
|
From: Serge E. H. <se...@ha...> - 2015-03-18 18:28:29
|
Hi, I don't believe what's going on is vimprobable's fault, but I don't know how to investigate further. I assume it's a webkit problem... I upgraded my laptop from Ubuntu utopic to Ubuntu vivid - this did not involve an upgrade of vimprobable2. But since I upgraded, I have to login every time I start a new vimprobable. stracing suggests that it is having no problem opening my cookies file. After logging in I can use the page just fine, but a new vimprobable has to log back in. I'll try testing with an older version of webkit, but was wondering whether anyone knew offhand what would be to blame. thanks, -serge |
|
From: Morgan H. <mt...@gm...> - 2015-02-20 05:52:02
|
On Fri, Feb 20, 2015 at 5:07 AM, Hannes Schüller <ha...@yl...> wrote: > I mean situations where a user would inadvertently allow settings for a > website he didn't intend. E.g. he would allow all cookies for a certain > website and then call another site (which he doesn't want to have those > privileges) in another buffer of the same window – *bam*, there are > all those tracking cookies written to permanent storage! Similar things > would apply to many settings. Ok, understood. Yes it does open up some new potential for users to make mistakes in that regard. Perhaps some of that behavior should be configurable, e.g. which settings carry over to new buffers and which use the defaults. As an aside, we may want to have some option of showing some of these security/privacy related things in the status url bar, or perhaps making the format of that bar entirely configurable. >> This is a good point, and something I hadn't really thought about as I >> hadn't yet run into this problem yet with vimprobable (unlike with >> chrome :). I put together a simple test html with a javascript >> infinite loop which, as somewhat expected, entirely hangs the browser. >> However, this problem also exists with the current master so I don't >> see that it's really anything specific to buffers aside from the >> annoyance of losing multiple open pages rather than just one. > > Well, I'd say that's a major difference. If one page misbehaves, I > don't mind killing and losing it. Pulling down other pages with it is > really annoying. But, well, it could be another one of those things > where people would just have to learn how to use it right, i.e. when to > open a new window and when to open a new buffer. As I said I was going to previously, I did spend some time yesterday and this morning looking into this. Unfortunately, it seems the options are fairly limited. Multithreading the GTK portion of the app like this is far from trivial as far as I can tell. The other option is to use webkit2 which is supposed to be able to handle this internally. This seems like the way we should go, but of course that's not exactly trivial either, and some people may not want or even be able to use webkit2 which requires gtk3. I'll spend some more time looking into it and see how difficult/ugly it would be to support both versions of webkit with some kind of thin wrapper layer. Let me know if you have any thoughts or suggestions on that. Regards, Morgan |
|
From: Hannes S. <ha...@yl...> - 2015-02-19 21:07:43
|
On Thu, 19 Feb 2015 10:54:02 +0800, Morgan Howe <mt...@gm...> wrote: > On Thu, Feb 19, 2015 at 2:39 AM, Hannes Schüller <ha...@yl...> > wrote: > > On Wed, 18 Feb 2015 01:17:26 -0500, Matthew Carter <m...@ah...> > > wrote: > >> I love that I can toggle what used to be tab specific features to a > >> set of buffers now. > > > > I'd say that's both the biggest strength and the biggest risk of > > this approach. If used right, i.e. for grouping pages of one > > website, this is extremely useful. If used wrong, i.e. to replace > > windows/tabs, this could lead to severe, unwanted breaches. > > Could you elaborate on this a bit? What kind of breaches are you > referring to? I mean situations where a user would inadvertently allow settings for a website he didn't intend. E.g. he would allow all cookies for a certain website and then call another site (which he doesn't want to have those privileges) in another buffer of the same window – *bam*, there are all those tracking cookies written to permanent storage! Similar things would apply to many settings. Things like this cannot be caught by technical means, of course. That is why I talked about *using* it right or wrong. > > Another thing to consider: How does the browser react if one of the > > buffers misbehaves, e.g. if the page in there won't stop executing > > some stupid script or something? Will it block all other buffers as > > well? Do I have to kill them all? > > This is a good point, and something I hadn't really thought about as I > hadn't yet run into this problem yet with vimprobable (unlike with > chrome :). I put together a simple test html with a javascript > infinite loop which, as somewhat expected, entirely hangs the browser. > However, this problem also exists with the current master so I don't > see that it's really anything specific to buffers aside from the > annoyance of losing multiple open pages rather than just one. Well, I'd say that's a major difference. If one page misbehaves, I don't mind killing and losing it. Pulling down other pages with it is really annoying. But, well, it could be another one of those things where people would just have to learn how to use it right, i.e. when to open a new window and when to open a new buffer. Hannes |
|
From: Daniel C. <dan...@gm...> - 2015-02-19 20:39:08
|
Matthew Carter <m...@ah...> wrote: > For whatever reason, printf output seems to be captured by the GTK main > loop until it terminates (hence why I chose stderr and not stdout for > this quickie approach to a buffer list available externally). The stdout is line-bufferd and stderr is not. To allow to print out immediately, you could call fflush(NULL); after printing to stdout. -- Daniel |
|
From: Morgan H. <mt...@gm...> - 2015-02-19 02:54:08
|
Hey Hannes, On Thu, Feb 19, 2015 at 2:39 AM, Hannes Schüller <ha...@yl...> wrote: > On Wed, 18 Feb 2015 01:17:26 -0500, Matthew Carter <m...@ah...> > wrote: >> I love that I can toggle what used to be tab specific features to a >> set of buffers now. > > I'd say that's both the biggest strength and the biggest risk of this > approach. If used right, i.e. for grouping pages of one website, this is > extremely useful. If used wrong, i.e. to replace windows/tabs, this > could lead to severe, unwanted breaches. Could you elaborate on this a bit? What kind of breaches are you referring to? > Another thing to consider: How does the browser react if one of the > buffers misbehaves, e.g. if the page in there won't stop executing some > stupid script or something? Will it block all other buffers as well? Do > I have to kill them all? This is a good point, and something I hadn't really thought about as I hadn't yet run into this problem yet with vimprobable (unlike with chrome :). I put together a simple test html with a javascript infinite loop which, as somewhat expected, entirely hangs the browser. However, this problem also exists with the current master so I don't see that it's really anything specific to buffers aside from the annoyance of losing multiple open pages rather than just one. I'm on Chinese New Year break starting today through the weekend, so hopefully I'll have some time to think about it and take a stab at this issue. Possibly something as simple as dispatching loads to a worker thread, which would be beneficial anyway as even pages that load slow currently stall the gui. > I definitely believe this is worth pursuing to see what can be done – > just needs to be considered carefully before merging this into the main > branch. Agreed, and it's good that people have taken some interest in this. It seems people really do have quite varied usage patterns, so you guys have already brought up a number of things that I hadn't considered for my workflow. Regards, Morgan |
|
From: Valentin R. <sou...@ru...> - 2015-02-18 22:01:53
|
* Morgan Howe <mt...@gm...> [2015-02-18 12:55:47 +0800]: > On Wed, Feb 18, 2015 at 8:19 AM, Jason Ryan <jas...@gm...> wrote: > > On 18/02/15 at 01:05am, Valentin Rusu wrote: > >> > >> Hello list, > >> > >> Trying to switch to vimprobable2, which I find really kool, I'm now > >> visiting my usual websites. And there's a problem when trying to log-in > >> to plus.google.com > > Putting "set cookies=true" in your vimprobablerc fixes the issue for > me (the default is no_third). I put that, then I also modified config.h to accept third party cookies. > > > I get a “Your browser is no longer supported” message. > > I still get a similar warning in gmail (even though it works) so you > might have to fiddle with your useragent string to get rid of that. I changed the useragent string to something like this: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2227.0 Safari/537.36" Now I'm logged into g+ with vimprobable2 and I think I'll stick with it a while :-) Thanks for the help, -- Valentin |
|
From: Hannes S. <ha...@yl...> - 2015-02-18 18:40:05
|
On Wed, 18 Feb 2015 01:17:26 -0500, Matthew Carter <m...@ah...> wrote: > I love that I can toggle what used to be tab specific features to a > set of buffers now. I'd say that's both the biggest strength and the biggest risk of this approach. If used right, i.e. for grouping pages of one website, this is extremely useful. If used wrong, i.e. to replace windows/tabs, this could lead to severe, unwanted breaches. Another thing to consider: How does the browser react if one of the buffers misbehaves, e.g. if the page in there won't stop executing some stupid script or something? Will it block all other buffers as well? Do I have to kill them all? I definitely believe this is worth pursuing to see what can be done – just needs to be considered carefully before merging this into the main branch. Hannes |
|
From: Matthew C. <m...@ah...> - 2015-02-18 07:42:46
|
Matthew Carter <m...@ah...> writes: > Matthew Carter <m...@ah...> writes: > >> Morgan Howe <mt...@gm...> writes: >> >>> This patch adds basic support for handling multiple buffers. New >>> commands are ":buf[fer], :badd, and :bdelete". Buffers are given a >>> unique constant buffer id starting at 1 in the same manner as vim. >>> >>> <snip> >>> >>> Regards, >>> Morgan >>> >>> ------------------------------------------------------------------------------ >>> Vimprobable-users mailing list >>> Vim...@li... >>> https://lists.sourceforge.net/lists/listinfo/vimprobable-users >> >> Very nice Morgan, built cleanly and works great so far. >> >> I love that I can toggle what used to be tab specific features to a set >> of buffers now. >> >> For instance, if I have a few sites that I want to run with javascript >> enabled, I can open them all in buffers in one tab, do a: >> >> :set javascript=on >> >> And as I refresh the pages (or do the set initially) they'll all retain >> the setting. Then my next tab of buffers will use my defaults. >> >> I don't like typing :buf 1, :buf 2 though, I'd like to use what I use in >> vim, a simple :b1, :b2 (and :ls for listing the buffers). >> >> Maybe I'll expand on your patch unless you plan to (or there was a >> larger reason for not using the shorter syntax). >> >> Just a wishlist item, but some type of command to open a "set" of >> buffers defined in the RC file would be pretty awesome (for instance, I >> could define news aggregates as something like: >> >> :set NA=reddit.com,slashdot.org,hackernews.com >> >> And then run something like: >> >> :bufaddset NA >> >> To automatically open up all 3 pages at once. >> >> For grouping, I can't imagine a better set up (where I could have news >> buffers in one tab, social media in another, programming resources in >> one and miscellaneous elsewhere). > > Usability issues I see so far: > > 'd' - I think this should close the current buffer, not the > whole window if we do use these buffers > > '^6' - This should switch between most recent buffer and > current buffer instead of tabs (at least when buffers exist). > > Maybe keep gt/gT bound for tab cycling still. > > Thats all I can think of for now. Attached is a patch for a buffer list function callable via 'ls' command that will display the results inline (similar to the stumpwm modeline, with * indicating the selected buffer and - indicating others). At the moment I'm also logging it to stderr so it is reusable outside of vimprobable2 by doing something like: ./vimprobable2 > /tmp/bufls tail -f /tmp/bufls | grep -C1 '---BUFLS---' Which would allow displaying the buffer list in a window manager area (or anywhere consistently). A better solution would probably be to (optionally) log to a file, if this was functionality that wasn't too much bloat and would be used by users. For whatever reason, printf output seems to be captured by the GTK main loop until it terminates (hence why I chose stderr and not stdout for this quickie approach to a buffer list available externally). |
|
From: Matthew C. <m...@ah...> - 2015-02-18 06:33:15
|
Matthew Carter <m...@ah...> writes: > Morgan Howe <mt...@gm...> writes: > >> This patch adds basic support for handling multiple buffers. New >> commands are ":buf[fer], :badd, and :bdelete". Buffers are given a >> unique constant buffer id starting at 1 in the same manner as vim. >> >> <snip> >> >> Regards, >> Morgan >> >> ------------------------------------------------------------------------------ >> Vimprobable-users mailing list >> Vim...@li... >> https://lists.sourceforge.net/lists/listinfo/vimprobable-users > > Very nice Morgan, built cleanly and works great so far. > > I love that I can toggle what used to be tab specific features to a set > of buffers now. > > For instance, if I have a few sites that I want to run with javascript > enabled, I can open them all in buffers in one tab, do a: > > :set javascript=on > > And as I refresh the pages (or do the set initially) they'll all retain > the setting. Then my next tab of buffers will use my defaults. > > I don't like typing :buf 1, :buf 2 though, I'd like to use what I use in > vim, a simple :b1, :b2 (and :ls for listing the buffers). > > Maybe I'll expand on your patch unless you plan to (or there was a > larger reason for not using the shorter syntax). > > Just a wishlist item, but some type of command to open a "set" of > buffers defined in the RC file would be pretty awesome (for instance, I > could define news aggregates as something like: > > :set NA=reddit.com,slashdot.org,hackernews.com > > And then run something like: > > :bufaddset NA > > To automatically open up all 3 pages at once. > > For grouping, I can't imagine a better set up (where I could have news > buffers in one tab, social media in another, programming resources in > one and miscellaneous elsewhere). Usability issues I see so far: 'd' - I think this should close the current buffer, not the whole window if we do use these buffers '^6' - This should switch between most recent buffer and current buffer instead of tabs (at least when buffers exist). Maybe keep gt/gT bound for tab cycling still. Thats all I can think of for now. -- Matthew Carter (m...@ah...) http://ahungry.com |
|
From: Matthew C. <m...@ah...> - 2015-02-18 06:17:35
|
Morgan Howe <mt...@gm...> writes: > This patch adds basic support for handling multiple buffers. New > commands are ":buf[fer], :badd, and :bdelete". Buffers are given a > unique constant buffer id starting at 1 in the same manner as vim. > > <snip> > > Regards, > Morgan > > ------------------------------------------------------------------------------ > Vimprobable-users mailing list > Vim...@li... > https://lists.sourceforge.net/lists/listinfo/vimprobable-users Very nice Morgan, built cleanly and works great so far. I love that I can toggle what used to be tab specific features to a set of buffers now. For instance, if I have a few sites that I want to run with javascript enabled, I can open them all in buffers in one tab, do a: :set javascript=on And as I refresh the pages (or do the set initially) they'll all retain the setting. Then my next tab of buffers will use my defaults. I don't like typing :buf 1, :buf 2 though, I'd like to use what I use in vim, a simple :b1, :b2 (and :ls for listing the buffers). Maybe I'll expand on your patch unless you plan to (or there was a larger reason for not using the shorter syntax). Just a wishlist item, but some type of command to open a "set" of buffers defined in the RC file would be pretty awesome (for instance, I could define news aggregates as something like: :set NA=reddit.com,slashdot.org,hackernews.com And then run something like: :bufaddset NA To automatically open up all 3 pages at once. For grouping, I can't imagine a better set up (where I could have news buffers in one tab, social media in another, programming resources in one and miscellaneous elsewhere). -- Matthew Carter (m...@ah...) http://ahungry.com |
2 messages has been excluded from this view by a project administrator.
