On Fri, 2005-09-09 at 11:45 -0300, BG - Ben Armstrong wrote:
> On Thu, 2005-09-08 at 10:49 -0400, Steve Hall wrote:
> > A good temporary solution would be:
> Thanks. That works well enough.
> I'm wondering, though, if the modification flag could continue to be
> set, only far less frequently. I understand why the statusbar needs
> to be updated on the fly (e.g. to handle the updated current line
> #,) even when only scrolling, but ideally we don't need to worry
> about the modification flag at all when we're doing nothing but
> scrolling. Unfortunately, I don't know how we'd tell the difference
> between scrolling and other kinds of activity in the buffer, any of
> which might cause updates to the buffer. Can you think of any way?
> Also, once the modification flag is set, couldn't we stop checking
> it until the user performs an undo? Or are there ways other than
> undo of reverting to an unmodified state?
I'd rather not add overhead to monitor all the conditions that could
cause a buffer modification. Besides, getbufvar() really should not be
checking the file in the first place, only the buffer. That appears to
be a Vim bug that would require too much effort on Cream's part to
> > I suppose we could make these automatic with some cream-conf var.
> > But I've also been thinking about adding "performance settings"
> > for large or high latency files. They could be meta controls for
> > items like those above, as well as &lazyredraw, &swapfiles,
> > &backup, :syntax and whatever else typically causes performance
> > problems in select situations.
> That sounds reasonable, although it would certainly be better if we
> could find compromises that improve performance without losing
True. Perhaps I'll ask on the vim list.
Steve Hall [ digitect mindspring com ]
:: Cream... something good to put in your Vim!