[Vimperator] Vimperator - relative tab movement and tabsearch patch

[Martin Stubenschrott]

On Thu, May 24, 2007 at 07:37:09PM +1000, Doug Kearns wrote:
> 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?

Actually right now I think, having a high-level API which support
"advanced" features like "overloading" with convenient functions makes
sense, and the ex commands just calling them with the right parameters
and doing the error reporting. If the vimperator.tabs. API just accepts
indices, it will really just be a wrapper to the firefox commands.

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

Great! I always wanted to have this feature. If we have it, then :map
support should be quite trival.
For new functions please put them in the vimperator. namespace instead
of global functions. (As :normal is an ex command, it probably should go
into vimperator.ex.normal() or vimperator.commands.normal(), which isn't
a problem for the main vimperator code, but for .vimperatorrcs, the
extra vimperator. probably is a little overkill, I'd really love to port
vimperator to javascript 2.0 when firefox finally supports it).

> Well that would more likely be: v.tabs.move(v.tabs.current + 1) or
> similar.

In fact it would be:
vimperator.tabs.move(vimperator.tabs.current(), vimperator.tabs.current() + 1);


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

The user would have to read the API docs anyway to use these functions,
and there the concept of the spec is explained.
BTW: I just renamed removeAllOthers to keepOnly, much better name;

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

Hmm, would be nice probably. I am not sure for .reload("*") or
.reloadAll(); but you're right would make sense. (* would expand to [0,
2, 3, 4,...], and the reload function could then check if it is an array
and reload all these tabs.

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

Hmm, I don't see it twice in mutt.

But the more I talk about the API, the more I see how difficult it is to
design a good one :( That's why I did not answer all your questions,
just because I don't know an answer to most of them :( And I am really
50:50 for your and for my proposal as I think, both have advantages.

So the question is, how do we continue from here, I really would like
the api to be kinda fixed before 0.5 is released.