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

[Peter Jakobi]

On Tue, Jun 26, 2007 at 04:52:47AM +0200, Martin Stubenschrott wrote:
> 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.

As  the  entabbed  par is quoted from the conkeror wiki, it might
be a good idea to tab the conkeror programmers / mailinglist on
this issue, as it's biting both extensions.

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

I  don't  really  care,  as  long as the problems are localized.  I.e.
a single _visual_ discontinuity doesn't jump wildly around.

Consider e.g.  linux.com and their page-navigation css BUG - kind of a
css-floating  div  disabling  some  links (at least for mouse clicks).
But such uses tend to be highly localized.

Given what vimperator quickly does when pressing f, displaying
the numbers would work well enough, and if we could detect visual
dicontinuities and change e.g. the color of the numbers for the
pair of numbers involved?  Place an arrow between those?

But  my guess for the least visually confusing approach would
probably to just "increase the redness" of the number's  background
per  "float" / "absolute-fixed" / "layered DHTML"(?) object entered.


> > 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 :/

Reliably? 

We've some visual discontinuity. Ok. We only need one aspect
of hard reliability - an object needs to be identified by one number
over the page-view / form lifespan (form, as inline js
may validate form input and redisplay something, in which case renumbering
might be necessary)


> [i to go to the previous image, ]t to the next textbox, 3]b to the 3rd
> next button, etc.

what's better here:
- explicit coding per class of objects or 
- (incl. user-defined) mapping of regex searches to a key

For the 2nd variant, dom-2-text would need to create 2 text strings,
one plain text for default searches, and an alternate one with object
class names (or whatever) inline to be searched, if the regex includes
some 'object-class' (e.g. to be treated as some special character 
class [[Hx]] in the regex expression, to be expanded for the actual
search in the alternate text string)


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

good. 

You do include counting the floats and just approximate the position?
Or do you have some code to detect floats/fixed-pos/columns?


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

Hmm.  Wouldn't both search and hints profit from a line number
scheme?  IMHO  having  one  would  allow  us to treat both
differently and at a higher level.

And  trivial  numbering schemes exist (tree traversal order, for
one). 

The problem is "merely" how  to  reduce  "number"  length
and  visual confusion (discontinuities,...) to something that makes
them usable for line-range-entered-by-user-navigation in a GUI.


[[that's basically the reason for me being very reluctant 
to give up on some kind of line numbers: generalize one key
problem, to be able to be lazy with the rest - as well 
as line-numbers being a perfect fit for anything vi-ish :).

Of course, those numbers are really soem kind of object-handles 
or tree-node-numbers, just trying hard to look similar
to line-numbers to fit with the vi metapher and be usable
internally and in :ex commands]]

-- 
cu
Peter
jakobi at acm.org