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

[Peter Jakobi]

On Mon, Jun 25, 2007 at 11:04:46AM +0200, Martin Stubenschrott wrote:
> On Mon, Jun 25, 2007 at 12:14:42AM +0200, Peter Jakobi wrote:

Rehi Martin,

first off, I don't know off-hand of any language offering efficient
regex support on objects. The best you could hope for would be a
grep coded in C on an object collection or tree. The overhead of
setting up the string match itself however would remain.

Matching  once  in  a  large  string  is bound to be more efficient in
general, even without using tricks like perl's study.



> > 1)  vi is about text; so mapping the dom representation of the page to
> > a plaintext view (with location information) should  be  possible
> 
> It isn't really that easy, actually impossible, because even if you
> managed to get this text representation with location information it
> would be nearly impossible to then get back from the text representation
> to the DOM, which you need for highliting the text. 

Hmmm. Indeed? I'd say it's neither actually nor nearly impossible :)

We  can  have  2  representations,  one  inline, one consisting of the
flattened text and say an array of pointers to objects.

The  inline  one  would  require  to  use  ascii represenations
of the pointers, and be marked with an illegal special char,
so  matching  it would  fail  (or  it would be easy to check
forward/backward to reject the match and look for the next).
A bit messy.

My  pref  would  be  to  use a normal string however, and just
have an array with string locations and corresponding objects.
It  would  be sorted,  so  just  look  for  the  index that's lower
or equal to your current position.  For highlighting we match again -
exactly  -  this time  in  the  objects  own  string.   So I don't
see any problem with mapping between the two representations. 

Furthermore,  consider  the things that can change separately (I
don't want having changing 'line numbers' in a page just because  I
entered text  into  a  form field).  So 'ordinary' pages are static
and we can cache the mapping and reverse mapping from string to text.

One  prob  would  be  pages with javascript hiding/displaying
changing information.  Here we'd probably need  to  refresh  the  map
for  any search/line numbered-move.  Unless you can promise that no
keys/clicks went  to  the  page's  inline  javascript.  But there
are also timers.  Messy.  No way but to offer an option  to  'set
the  quality  of  the match':  static  vs  'refresh each time for
certain ops'.  Should be a tab-local or url-prefix-specific setting.
Or are there hooks that notify on dom content changes?



> Regexp would really
> be fine in vimperator, but I think we'll have to wait for firefox to
> support it (there is a feature request for it AFAIK).
...
> Of course javascript has regexp support, but for text, not for a complex
> web page.

do we need perl's pos?  search seems to include this functionality,
so we're  fine.  The /o modifier should be irrelevant given we can
create regexp objects in js.

However  study()  for  caching  the  internal  setup data for
the text matching automaton (like  in  the  guts  of  perl/pcre)
seems  to  be missing;  which  would  slow  down repeated matchings
on the same text string.

One  final  caveat: even in perl5, never try for a regexp that
matches more than 64K of characters in a larger string.   The  grue
will  eat your match.



> PS: Is there a way to turn off the justified text in your mail editor?
> I think it's sometimes very hard to read the text in justified but still
> monospace text.

Well, I could use another formatting key in vim for this message.
Better?


PPS:  Firemacs:

Had  a  quick  look at mozless (not interesting, I'd say) and firemacs
(not very interesting, allows editing in text fields with  some  emacs
bindings,  no  minibuf; setting marks/copy/kill-to-end of line in text
fields.  I couldn't  make  the  copy/kill-regions  keys  work;  except
outside of input fields with the result of the tab closing :> ).


-- 
cu
Peter
jakobi at acm.org