[Vimperator] request statusbar / q regex / possible bug: 'all extensions incompatible'

[Martin Stubenschrott]

On Tue, Jun 26, 2007 at 02:05:26AM +0200, Peter Jakobi wrote:
>    It would be nice to instrument the DOM with numbers as it is being
>    loaded, rather than after.

Definitly, I just haven't found a way to do that :( I even thought about
writing a C++ component for the hints, but dropped the idea for now as i
don't have so much time :( The only event I know right now is
DOMContentLoaded, but this still is too late to make them appear
instant.

> Ok  Martin,  Nigel  and co, let's brainstorm a bit wrt line numbers
> - that way, I'm not the only one I'm currently confusing :>.

:)

> [In the mean time, I'll  take  a  look at conkeror and the vimperator
> cvs (Martin: I'll probably take the bait and have a look at regex).]

Yeah good idea, CVS has changed so much architecturaly, it doesn't make
sense to look at the old 0.4.1 code.

> I'd be especially interested in design decisions already made for
> some of  the points below, esp.  as a line numbering concept is
> also needed to return regex results or rather  to  act  on  them.
> And  with  vi, usually  you  can use relative moves, % numbers,
> line numbers or regex interchangably :).

While I love line numbering in vim, I think it can't work in vimperator.
Why? Because:
a) A document can have (i)frames
b) A document can have different fontsizes and weird CSS like position:fixed; top: -100px;

> What  do we know about line numbers?  Other than that they're
> strictly monotonous?
>
> What  should be numbered?  Lines of the on-screen layout?  Or rather
> a subset of dom objects (1st  paragraph,  2nd  paragraph, 3rd
> frame(!?))?

See above, I think web pages can't be numbered reliably :/

> [probably not, they shouldn't have a class of their own; I'd
> prefer to be  able  to  navigate  to  them  by  regex  movement,
> something like /[[CLASS:Hx]]/ for jumping to the next Hx heading, or
> whatever's  the style  du  jour  of  referring to POSIX char classes.
> That would also work for navigation/jumping/selecting links.]

Navigation for such things is planned, but with other keys:
[i to go to the previous image, ]t to the next textbox, 3]b to the 3rd
next button, etc.

> What about % navigation?

Well, we already have count support for gg which works like this, so
30gg goes to 30% of the web page.

> And  a  bit problematic: objects that include subtrees: e.g.
> iframes, possibly with their own scrollbars.  Form fields with
> multiline  text.  Or simple frames. [a tree-ish notation would allow
> inclusion of inclusion of arbitrary subtrees (iframes, ...)
> without having to renumber any other node (e.g. those following
> the iframe). ]
> 
> How do we enumerate iframes, ...? Do they count as 1 or as
> more depending on their size? 
> 
> Javascript?
> 
> What's the "size" of objects not currently rendered?  Do they count
> as 0  (object  doesn't  have  a line number of its own), 1 or as
> "maximum possible visible size"?

So you see yourself, line numbers probably aren't doable in a web
browser :( I think there are much more important things like a better
hints-implementation or a search implementation.

> How to implement :set number? 
> 
> How to display the current line/position in the status bar 
> (with some :settings)?
> 
> How  to  display  the  current  position  in  the  document (with
> some :settings)?

All these things are trival then, but the numbering itself isn't.

> Are marks already implemented in CVS?

Yes.

> PS:  Sorry  Martin, my fmt macro indeed seems a bit broken, just
> saw a few cases, where  fmt  with  non-justification  kept  multiple
> spaces needlessly.

No problem, just 2 instead of 5 spaces is at least readable :)

> cu & good night,
> peter

Good night,

Martin