[Vimperator] Vimperator - relative tab movement and tabsearch patch

[Doug Kearns]

On 5/23/07, Martin Stubenschrott <stubenschrott at gmx.net> wrote:
> On Tue, May 22, 2007 at 10:09:15PM +1000, Doug Kearns wrote:
> > I've also left some comments in there to remind me to look at some
> > sort of command argument parser.  Having to handle ex-command args all
> > over the place is grossing me out. ;-)
>
> I am sorry, but I really thought that handling of relative strings
> should be in the tabs API. In my opinion the big difference between the
> API and the ex-commands is, that e.g. the Tabs() api should just return
> true/false/null etc. (or maybe exceptions?) which can then be checked by
> a caller like the ex-commands to show an error message.

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

> The API is designed for quick an easy vimperator plugin writing in
> future, and it doesn't make sense to me, that the plugin author has to
> either use the ex-command or even doing some manual calculations to
> select the next tab. Therefore I decided that the
> vimperator.tabs.{move/select} methods should have a logic to handle
> "[+-]num" arguments.

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

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

> Also the remove method will later be changed to return true/false wheter
> the tab could be removed. This return value would then be checked by a
> vimperator.commands.quit() ex-command and then vimperator be quit in
> case of the last tab.

Shouldn't we be throwing exceptions here rather than passing around
error/return codes?  I suspect we're in trouble if we can't remove a
tab.

> I am not really sure, if we need the index() and count() methods, but I
> thought, the vimperator-plugin writer should not have to deal with
> firefox methods at all, but can rely that all important features can be
> accessed from the vimperator API.

Yes, although tabs aren't really the best example since we shadow
TabBrowser so closely anyway.

> Please complain about missing/wrongly-named, etc. methods now.

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?

I'm not sure about 'get'..

> CC'ed to the ML if others want to comment on the Tabs() API.

Yes, that relative motion/wrap tab patch should have gone via the
mailing list too.  Sorry about that.

Regards,
Doug

PS. Sorry I'm in a bit of hurry but I'll think more about this tonight.