[Vimperator] Vimperator - relative tab movement and tabsearch patch

[Martin Stubenschrott]

On Fri, May 25, 2007 at 02:14:15AM +1000, Doug Kearns wrote:
> I really don't think having to change to a tab before deleting it in a
> user script/command is too onerous.  At least for now...

We could add an optional :bdelete [index] to the ex command as well,
because I dislike the idea of first selecting a tab to delete it.

> Adding a whole new level of abstraction just so a user can do:
> 
> v.tabs.keepOnly('+2')
> 
> instead of:
> 
> v.ex.tabmove('+2')
> v.ex.tabonly()
> 
> doesn't make any sense to me.

We could add an optional index to ex commands like tabonly() as well,
this is not vim compatible, but then all the functionality would be
also available for the ex-commands.

BTW: .tabmove() will MOVE a tab, you
probably wanted to select a tab which is not really available as an ex
command (well you could use :buffer 4, but this does not take a
relative position).

> I guess we could even add the "$" arg to the tabmove ex-command if you
> felt it was clearer than having no arg take you to the last postion
> which is how Vim does it.

I think for this ex-command an empty string OR $ should go to the last
tab.

> I don't know what your position on
> compatiblity with Vim's commands is but I don't see it as a problem if
> Vimperator offers a superset of its functionality.

I like to be compatible to vim where it makes sense, but not everywhere.
E.g. I use list:full as the default wildmode, while vim does not show
the list von <tab> by default.

> > If the vimperator.tabs. API just accepts
> > indices, it will really just be a wrapper to the firefox commands.
> 
> Yes largely, but we're using a bad example with tabs because the
> TabBrowser API is pretty complete. All I think that's really needed is
> a thin wrapper that shields you from changes to TabBrowser, adds
> convenience methods, and provides the missing functionality which is
> important in the context of Vimperator but not available in TabBrowser
> like the ability to reload all tabs bypassing the cache etc.

Jup, sounds reasonable.

> Touche! ;-)  But, to be honest, I think the whole interface is wrong
> at this level and v.tabs should really just be manipulated through a
> standard list interface...

What you mean with "standard list interface"?

> To be honest I think worrying about a low-level API as I described
> above is extremely premature and simply something to keep in mind
> whilst we improve the existing architecture.  I also think you're
> proposed high level API is really just the ex commands by another
> name.

You probably are right.
So my (last? :) ) proposal:

Change the Tabs() methods, so that they don't accept any arbitrarily
string like the ex commands but only an index.

Then the handling of advanced syntax like "+2" should be translated into
an absolute tab index by the ex command.
This conversion would be done by a modified
    function indexFromSpec(spec, wrap)
function, but moved to a private method to the Commands() class.

Right now I am too lazy and don't have time, but I'll give it a shot
before 0.5 if you don't come first :) As the weekend is reserved for the
girlfriend, you have time to hack around every part you like till monday
at least without fearing any big commits. :)

> So, IMHO, I think the best way forward is to make sure we have as much
> ex command coverage as possible and to make this available as the only
> API.  If users want to do something more sophisticated than is
> available via the ex commands then they can dig around in browser.jar
> like the rest of us. ;-)  I think it's infinitely more important that
> we have things like quality suport for :map and :command.

Yeah, but for this, we really should start to move the functions to the
already-existing Commands() class. (The class is called Commands because
it makes more sense, but should we use vimperator.commands. or shorter
and maybe clearer vimperator.ex. ?)

Before I do any work on :map or :command I want that 'vimperator' is the
only global object left.


Oh and another 'problem child' - echo():

Right now vimperator.echo() is a convenience shortcut to
vimperator.commandline.echo();
If you want to have all ex-commands available as vimperator.ex.* then we
would even have a 3rd echo() function - not what we want, or? So maybe
we need to drop vimperator.echo() then, or better suggestions?


Ah, and maybe we should change index() and count() to a normal variable
and define a getter function like this:
http://ajaxian.com/archives/getters-and-setters-in-javascript

and for the setter function we would echoerr("xxx is a readonly var");