emacs-devel
[Top][All Lists]
Advanced

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

Re: Unbalanced change hooks (part 2) [Documentation fix still remaining]


From: Eli Zaretskii
Subject: Re: Unbalanced change hooks (part 2) [Documentation fix still remaining]
Date: Tue, 30 Aug 2016 18:08:12 +0300

> Cc: address@hidden
> From: Daniel Colascione <address@hidden>
> Date: Mon, 29 Aug 2016 19:54:52 -0700
> 
> On 08/29/2016 07:38 PM, Eli Zaretskii wrote:
> >> From: Stefan Monnier <address@hidden>
> >> Cc: Daniel Colascione <address@hidden>, address@hidden
> >> Date: Mon, 29 Aug 2016 20:25:06 -0400
> >>
> >>>> #1 breaks the entire b-c-f model --- "hey, I'm about to modify the
> >>>> buffer, so throw away caches" ---- and can lead to anything with a
> >>>> cache flush in b-c-f (like syntax-ppss) not properly discarding
> >>>> out-of-date buffer information.
> >>> That single case of #1 is revert-buffer, which conceptually throws
> >>> away the entire buffer and replaces it with what's on disk.  That it
> >>> actually keeps portions of the buffer is an optimization, but the
> >>> concept still stands.  So I don't see how it breaks the entire model,
> >>> at least not in practice.
> >>
> >> The optimization is beside the point: not calling b-c-f in some corner
> >> case breaks the entire model because a user such as syntax-ppss relies
> >> on b-c-f to know when to flush its cache, so if you don't call it when
> >> the buffer is modified, the cache ends up stale.
> >
> > I'm saying that flushing the entire cache in that case is not a
> > problem, it's what needs to be done anyway.
> 
> How is a mode supposed to know that it's supposed to flush its cache?

I think I misunderstood you, sorry.  I thought you were saying that in
the absence of the before-change call a mode will decide to flush its
caches, and that you've considered such flushing a problem of some
sort.



reply via email to

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