Are buffers a more natural vim metaphor for having multiple web pages open?

[Jefficus]

I'm a long-time vi/vim user but new to vimb, and I absolutely love what I've seen so far. But one thing perplexes me. I completely agree with the idea of leaving tab management to some other tool, but it seems to me that vim already has a robust and powerful mechanism for dealing with multiple open files - the buffers.

A quick look online doesn't turn up any discussion of this alternate metaphor, so I thought I'd ask the question here. Has this already been considered somewhere and rejected? Because it seems to me that buffers are a key component of the vim metaphor, and would be a powerful (and totally vimmish) way to handle having multiple pages open in vimb.

[fanglingsu]

You are right, buffers are great. I've thought about buffers in the past too. But I saw some possible issues with the buffers. And because no one other ask for this feature I kept my fingers away from implementing them. Following issues made me think to not spend any work on buffers for vimb.

1. Vim is an editor and working on multiple files in parallel is a common use case. But for a browser this seems not to fit the way they where used. I read only one page and close it after working through. If I need it a long time like this github page I open it into a separate window/tab.
2. Vim opens a new buffer for each opened file. But I don't know when a browser should use a separate buffer for a page. Should each new page be opened into a new buffer? Or should only pages that where opened by :open or :tabopen be placed into new buffer?
3. It might depend on implementation, but I fear that a buffer in vimb would be something like a none shown webview. So each buffer would required a bunch of memory. So some new users who don't know something about the buffers would see a high memory usage. the more experienced users would also need to remove unused buffers to free memory. I don't like the idea to force the user to concern about clearing buffers to keep the memory footprintt low.
4. At the time each page shown in vimb is a separate process which provides some more security and make some things easier to implement.
5. At least there is not clear which settings should be applied to a page in a buffer in case the user toggles some settings during runtime (e.g. :set scripts!). Should this be applied on a per instance base or for the single buffer? If it's for the buffer we need some more logic to allow the user to change settings on instance or on buffer.

In conclusion I'm not sure if the buffers are really usable within browsers.

[Jefficus]

I agree that opening a new buffer every time a new URL is visited would be horrible. And allowing users to explicitly control when it happened (such as the :tabopen command) would be an excellent solution.

But I wasn't suggesting that you should implement the vim concept of buffers in vimb. I was only using buffers to demonstrate that vim already embraces the notion of having multiple "files" open at once, while only displaying one at a time. In the abstract sense, buffers and tabs are just two slightly different metaphors for accomplishing that same basic functionality. The only practical difference is whether you display a tab widget to control which open document is being displayed, or use hot keys and command mode invocations to control which buffer is being displayed. Either way, you end up with N pages open and show one at a time.

[Docbroke]

This may be good idea for reducing CPU consumption. Only page that is displayed consumes CPU while other pages simply stays in RAM. I think firefox has something like that, to keep multiple tabs open without using too much of CPU power.