[Vimperator] Vimperator - relative tab movement and tabsearch patch

[Doug Kearns]

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

Is my understanding above incorrect?  Just to reiterate, I was under
the impression that you were planning a high-level API (in practice
simply a programatic interface to the ex commands) and a low-level API
which would provide JALI (Just Another Level of Indirection) to using
the Firefox API and the guts of Vimperator.

It seems to me now that you wish to conflate these?

[That reminds me, I've also got a partial implementation of :normal
which I should finish off.]

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

But it's not really a string is it? :)

I think that the only reason for these short cuts, such as +N and $,
is interactive use where brevity is important.  Keystrokes are cheap
and I can't see any benefit to using the shortcuts elsewhere.

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

Well that would more likely be: v.tabs.move(v.tabs.current + 1) or
similar.  But I don't think an increase in the number of functions
necessarily equates to an increase in complexity.  I guess I come from
the Meyer school of  "everything should have its own name".

<snip>

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

Show that to someone and ask them what it does - then show them
v.tabs.removeAllOthers(v.tabs.last) or even
v.tabs.keepOnly(v.tabs.last).

Of course, a user familiar with the ex commands could just choose this
alternative:
v.ex.tabmove()
v.ex.tabonly()

Isn't removeAllOthers really just another convenience function like my
suggested moveLeft anyway?  Taking this spec idea to its logical
conclusion might leave you with something like v.tabs.remove('*',
'$').

> 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/);

Hmm, are you really just saying you'd prefer to trade new functions
for magic string parameters? Eg. v.tabs.reload('*') rather than
v.tabs.reloadAll(). If that's the case I think you're starting down
the path to some sort of DSL.  Which might be cool but, if so, I think
you should really go all the way. :)

<snip>

> > I'm not sure about 'get'..
>
> Well, it is definitly needed for things like buffer completion.

Yes, I just meant the name but I don't have an alternative right now.

<snip>

Regards,
Doug

PS. Is it just me (or gmail) or does the reply-to header contain the
list address twice?