Re: [vile] visual-matches

[Thomas Dickey]

On Wed, Oct 16, 2013 at 03:13:29PM -0400, Wayne Cuddy wrote:
> On Tue, Oct 15, 2013 at 08:23:28PM -0400, Thomas Dickey wrote:
> > On Tue, Oct 15, 2013 at 01:12:21PM -0400, Wayne Cuddy wrote:
> > > Understood. However for this command 'g/pattern/d', vile takes an
> > > incredibly long time with visual-matches enabled. If I set it to none,
> > > but leave syntax highlighting enabled (which I think I may have set to
> > > .5 or .75 seconds) it's a huge improvement.
> > > 
> > > What I'm asking is each time a line is removed, using the above
> > > command, does vile rescan the entire for for visual matches? Or does
> > > it do this after removing all the lines?
> > 
> > Looks like the former: in lremove (remove-line), vile is adjusting the
> > AREGIONS (attributed-regions) at that point, freeing the one(s) on the
> > deleted line.  Those include both visual-matches and syntax highlighting.
> 
> This makes sense then, because my command removed a large number of
> lines. I'm assuming that since it took so long to remove them and
> redraw the matches that the highlight filter was also executed several
> times as well?

no - that wasn't being run repetitively.  I profiled a case where I removed
"the" from a text file and it only repainted the screen 11 times during the
test (3 times while editing).  But it removed 4192 lines - and made 49505
calls to free_attrib2().  It was a small test - complicated by the syntax 
filter -
and the free_attrib2() calls are down the scale, but there are related
functions, and those do add up (as you've seen).

> 
> > 
> > That's a special-case (the other calls to free_attrib2 are in the bulk
> > re-highlighting functions).
> > 
> > It's simplistic of course: if there are few matches, then it's "fairly 
> > fast".
> > 
> > Alternatively, we could add a check to see if there have been more than 1-2
> > regions removed, and then simply remove all, and force a repaint.  (It would
> > be simpler if there were not also syntax highlighting - same problem).
> > 
> > However - if autocolor is set to some low value, then it might make sense
> > to do this.  It would be easier to decide if vile did a count first to
> > see how many lines were affected - but that takes time too, and the result
> > would not remember which lines.
> > 
> > On the other hand, it would be simple to implement, and we could have 
> > another
> > mode setting :-)
> 
> Are you proposing another setting for visual-matches?

A new mode (naming it is likely to be the hard part).  Maybe "visual-deletions".

That's a workaround: while I can "see" how I could rewrite a chunk of the
highlighting support to improve its performance, doing that's a fair amount
of work, and I've not found time for that.

I addressed the tcl filter stuff you reported, and that's in a patch here:

        ftp://invisible-island.net/temp/

but at the moment I'm working to close out issues with lynx for a release, and
thinking to spend a chunk of time on vile after that's done (with some work on
xterm in between...).

-- 
Thomas E. Dickey <address@hidden>
http://invisible-island.net
ftp://invisible-island.net

signature.asc
Description: Digital signature