[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [vile] visual-matches
Re: [vile] visual-matches
Wed, 16 Oct 2013 18:12:42 -0400
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
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:
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>
Description: Digital signature