Re: trunk r116426: * lisp/jit-lock.el (jit-lock-mode): Keep it disabled in indirect buffers.

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Note that if I am in the indirect buffer, I don't want to run
> base-buffer after/before-change-functions at all!

The problem is that you're not the only user of
after/before-change-functions.  In the general case, all the related
buffers might care to know that some part of their text has
been modified.

> Each time the after/before-change-functions are initialized in
> indirect-buffer I will have to somehow prohibit execution of the
> base-buffer change-functions and execute those from
> indirect-buffer.

Why prohibit the hooks from the base buffer?  If they're there it's
presumably because they're needed.

> Kinda mind-stretch. That there is no way to figure out indirect
> buffers from the base buffer complicates the stuff even further.

It's easy to find all the indirect buffers.  In your case you'll just
want to find the indirect buffer that corresponds to a particular buffer
position, and that's something I'd expect you need at other places anyway.

> More generally, the fact that hooks are not executed in current-buffer
> will probably cause havoc in other usages of indirect buffers. I imagine
> that all designers of after/before-change-functions assume that the
> action happens in the current buffer. Your proposal will invalidate this
> assumption.

Running the after/before-change-functions of the base buffer in the base
buffer means that "the action happens in the current buffer", and indeed
it does: a buffer-modification happens in all the related buffers, not
just in the one that happens to be current.

> In conclusion, unless I miss something essential, I don't see it as "the
> simplest option". The simplest option is to execute the hooks only in
> the buffer that initiated the hook (always current buffer?).

That means the other related buffers aren't told about the modification
in their text, which is also unexpected.

> What can go wrong with "run hooks in the current buffer only"
> implementation?

OK, let's say you chunks

    chunk 1 in mode A
    chunk 2 in mode B
    chunk 3 in mode A

And let's say that mode A does some clever caching, so it sets up an
after-change-functions hook to flush its cache.  Now you go and delete
a block of text in chunk 3, mode A is not warned about it and fails to
flush its cache which now holds completely broken data about chunk 3.

Of course, running the after-change-functions only in the base buffer
won't directly help with that.  I find such discussions depressing,
because they always go back to "indirect buffers are an attractive
nuisance", introducing more problems than they solve.

> The idea of indirect buffers is great.

On its own, it's almost great.  But once you throw in text-properties,
overlays, and buffer-local variables, plus the fact that the choice
between text-properties and overlays is never based on whether "it
should be shared between indirect buffers or not", plus ...  it's just
a big mess that just shuffles problems around without helping
solve them.


        Stefan