vile
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vile] visual-matches


From: Thomas Dickey
Subject: Re: [vile] visual-matches
Date: Tue, 15 Oct 2013 20:23:28 -0400
User-agent: Mutt/1.5.20 (2009-06-14)

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.

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 :-)
 
> So what I end up doing is disabling visual matches, using the global
> command to remove lines, and then re-enable visual-matches.
> 
> If I use a command such as '%s' to replace some text it's much faster
> than the global command which removes lines.
> 
> None of this is really an issue, just curious behavior.
> 
> Wayne
> 
> On Fri, Oct 11, 2013 at 05:41:40PM -0400, Thomas Dickey wrote:
> > On Fri, Oct 11, 2013 at 04:50:09PM -0400, Wayne Cuddy wrote:
> > > I have a file that is only about 30k lines. The command 'g/pattern/d'
> > > takes a very long time when visual-matches is enabled and is almost
> > > instant when set to 'none'. I'm curious to what would cause this? Is the
> > > match highlighter being executed after each line is remove when visual
> > > matching is enabled? Is there a way to have the g/v and other commands
> > 
> > yes - it is inefficient.  Essentially
> > 
> >     a) when the search command is issued, vile scans the whole file,
> >        computing the highlighting as a linked list
> >        (think of it as a transparent overlay).
> > 
> >     b) as it displays a page, vile looks in the list for chunks that
> >        fall on the page.
> > 
> >     c) doing an edit or other change that requires repainting the screen
> >        adds the overlay as in (c)
> > 
> > The same issue exists with syntax highlighting, though solving this one
> > seems less complicated.  (On the other hand, syntax highlighting
> > can be turned with the autocolor setting - that doesn't apply to
> > visual matches). 
> > 
> > > that modify text save, disable and re-enable visual matches so
> > > that I don't have to remember to do it?
> > > 
> > > Thanks,
> > > Wayne
> > > 
> > > _______________________________________________
> > > vile mailing list
> > > address@hidden
> > > https://lists.nongnu.org/mailman/listinfo/vile
> > 
> > -- 
> > Thomas E. Dickey <address@hidden>
> > http://invisible-island.net
> > ftp://invisible-island.net
> 
> 
> 
> > _______________________________________________
> > vile mailing list
> > address@hidden
> > https://lists.nongnu.org/mailman/listinfo/vile
> 
> 
> _______________________________________________
> vile mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/vile

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

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]