[Vimperator] Vimperator - relative tab movement and tabsearch patch

[Martin Stubenschrott]

On Wed, May 23, 2007 at 07:40:03PM +1000, Doug Kearns wrote:
> I thought that the client API would exist to provide an extended (over
> that offered by the ex commands) 'traditional' interface to Vimperator
> specific functionality and to wrap the Firefox API where needed to
> hide some of the underlying plumbing.
> 
> Users would then have the choice of using ex commands or the client
> API dependant on available functionality and personal preference.
> Much like Vim's current use of ex commands or builtin functions in Vim
> Script.  Call me old fashioned but I consider having a function's
> behaviour change based on whether you pass it "+5" or 5 to be
> seriously weird. :)

Hmm, maybe you aren't that wrong. I have to think about it.
Maybe we should drop the number version at all and always require a
string spec like "5" instead of 5? Probably not wise, but it may make
things clearer for you (and others).

> Why not offer convenience functions like v.tabs.moveLeft(count, wrap)
> and v.tabs.moveRight(count, wrap) ?

Hmm. And also having v.tabs.selectNext(...) etc. - that's really not a
clean API IMHO, and probably more code duplicated.

> > Apart from that, the Tabs() API seems quite finished for me, probably we
> > should add a vimperator.tabs.add(...) function, and allow indices
> > instead of tabs objects in the various functions.
> 
> Yes, but I'm not sure 'overloading' these functions is the best method.

The advantage of 'overloading' all these functions with using a "spec"
instead of an index/tab/... is that it's easy to write functionality which
are not ex-commands.
E.g. the user can do a:
vimperator.tabs.removeAllOthers("$"); to remove all but the last tab.

Also it would be easily possible to extend the spec at some point, and
all commands would benefit from it. Like:
vimperator.tabs.select(/regexp/);

> I'd assume that index() took a tab argument and returned its index in
> the list.  How about selected() returning the selected tab and
> selectedIndex() returning the index?

Sounds good. Probably currentTab(spec) and currentIndex(spec); is better
than selected*()? On the other hand, current does not really go well
with an optional spec argument either.

> I'm not sure about 'get'..

Well, it is definitly needed for things like buffer completion.

--
Martin

PS: Hopefully you could follow a little my weird brain, it's not so easy
to think about a good API.