[Vimperator] Vimperator - relative tab movement and tabsearch patch

[Doug Kearns]

On 5/25/07, Martin Stubenschrott <stubenschrott at gmx.net> wrote:
> 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.

Yes, I hadn't noticed that was missing yet.  I'll add it if you like.

<snip>

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

Can't hurt...

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

Sorry. I obviously didn't update my example properly, from an earlier
one, before sending but I'm glad you read minds - that should make
things easier. :)

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

Sounds good.  That will provide three options though, :tabmove,
:tabmove 999, tabmove $

<snip>

> > 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"?

The data type.  This discussion regarding move(), and similar
functions, is just a result of the needs of the interactive commands
where having singular actions is important.  But since v.tabs is
really just a list I expect a standard list interface should work
well. ;-)

I was basically just repeating myself...

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

That's pretty much what I had in mind.

> This conversion would be done by a modified
>     function indexFromSpec(spec, wrap)
> function, but moved to a private method to the Commands() class.

Ultimately it might be nice to have an Argument Parser that accepted a
full argument specification of some sort.  This could specify the
args, types, default values, and whether {count} or [!] can be used.
I suppose this could also be used for generating the usage strings.

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

What? Developers have girlfriends now? ;-)

<snip...some questions to answer when I have a clearer picture>

> 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

Yes these should be properties.

Regards,
Doug