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

[Peter Jakobi]

On Mon, Jun 25, 2007 at 10:32:19PM +0200, Martin Stubenschrott wrote:
> On Mon, Jun 25, 2007 at 03:19:40PM +0200, Peter Jakobi wrote:

> You may also have a look at conkeror.mozdev.org, it is something like
> vimperator for emacs users.

conkeror 
   To make that happen, I would like to rework conkeror's numbered
   links system, so that any kind of element, or group of element, can
   be numbered on the fly, and the user would be prompted to enter the
   number of the textarea they want to edit externally.
...
   I  would  like to make a general module called Numbering that would
   be capable of numbering not just links and images, but any type  of
   element or various groupings of elements.
   --RetroJ
...

sound like they're also playing with some of those rough ideas.

   It would be nice to instrument the DOM with numbers as it is being
   loaded, rather than after.



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


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


What  do we know about line numbers?  Other than that they're
strictly monotonous?

Nice to have: they should  be  constant  for  a  given   object
over   the time-to-live of the page and be usable for vimperator
movements.

Optional: they might be continous or they might skip some numbers?

What  should be numbered?  Lines of the on-screen layout?  Or rather
a subset of dom objects (1st  paragraph,  2nd  paragraph, 3rd
frame(!?))?

Are our line numbers numerical?  
Or should we use a more generic concept?

A  tree-ish notation  with multiple dots (might require some rules
to shorten this "number" or "path" in the dom tree; roughly like
the SNMP numbering scheme), or just incremental?

Should  we have multiple classes of numbers (i.e.  prefix L denoting
a link?)?  Do we want to have any kind of relationship between
numbered classes?

Should we number headlines, regardless of their level?  

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

What about % navigation?



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

[form fields can be modified by the user.  Is it a good idea that
user input in such a field force renumbering other object numbers?
Vi does it all the time, quite successfully... and ctags and stuff
sometimes switch to regex instead of line numbers to cope with it.]


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

The whole movement and display of the cursor mark should 
cooperate/extend the existing ability to tab to links and
highlight them.

--

All we seem to have currently is relative movement.

Are marks already implemented in CVS?
(if not, is it indeed the -> "numbering issues not yet decided on"-bug?)



--

> PS: It's sometimes hard to follow your messages, as you seem to jump
> around quickly with your thoughts ;) No offence meant, still good you
> give some input.

Well,  if I'm still playing with ideas at such a high level I
wouldn't want to restrict my thinking early.  Esp.  concerning
numbering  which be  restricting  later on depending on the chosen
implementation.  See above conkeror quote :).


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.

-- 
cu & good night,
peter
jakobi at acm.org