vimprobable-users

[Vimprobable-users] RFC: Added support for buffers

[Morgan H. <mt...@gm...>]

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.

The :badd command takes an optional url argument which it will open
when creating the buffer. If none is provided, it will open a new,
blank buffer.

The :buf[fer] command allows changing to another buffer in the buffer
list and supports tab completion.

The :bdelete command also supports tab completion and takes an
optional buffer argument and deletes it. If no argument is provided,
the current buffer is deleted.

I tried to as closely as possible follow the behavior in vim so that
it would be familiar to use and have been using it for several months
now. The buffer naming used in the tab completion is kind of clunky
but it works well enough. Other than that, I haven't had any serious
problems or complaints.

Please discuss if this is even something we think is worth adding, if
we should make it a compile time conditional feature, if you have
better suggestions for the implementation or tab completion, etc. I'd
appreciate any feedback. And of course please try it out. :)

*NOTE: This patch builds upon my previous patch just submitted to the
list regarding the commands list and COMMANDSIZE variable. These 2
patches are obviously conflicting, so you'll need to apply that one
first to test the buffer support. These changes are also in my
for-next branch on SF.

Regards,
Morgan

Re: [Vimprobable-users] RFC: Added support for buffers

[Matthew C. <m...@ah...>]

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

Re: [Vimprobable-users] RFC: Added support for buffers

[Matthew C. <m...@ah...>]

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

Re: [Vimprobable-users] RFC: Added support for buffers

[Matthew C. <m...@ah...>]

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).

Re: [Vimprobable-users] RFC: Added support for buffers

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

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

Re: [Vimprobable-users] RFC: Added support for buffers

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

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

Re: [Vimprobable-users] RFC: Added support for buffers

[Morgan H. <mt...@gm...>]

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

Re: [Vimprobable-users] RFC: Added support for buffers

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

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

Re: [Vimprobable-users] RFC: Added support for buffers

[Morgan H. <mt...@gm...>]

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