Re: jit lock sit-for provokes redisplay provokes imenu

[martin rudalics]

> This change, with the design I proposed, is so simple that it can't
> break anything.  It would enable us to get rid of a gross
> inefficiency, which is a kind of bug.  So I think we should do it now.

The following questions would have to be answered before doing that:

1. Should the value returned by `buffer-chars-modified-tick' always
(invariantly) imply the value returned by `buffer-modified-tick'?  With
other words, suppose we have a thing called CHAR_MODIFF: Would we have
to support the invariant

                  MODIFF >= CHAR_MODIFF >= SAVE_MODIFF

In my opinion it seems counterintuitive to say that a buffer is "not
modified" but a "character insertion and/or deletion has occurred".
Hence I think the answer is yes.

Affected seem (at least): `write-region', `insert-file-contents',
`set-buffer-modified-p' and `restore-buffer-modified-p'.  Any more?


2. Things like `subst-char-in-region' with NOUNDO non-nil change the
buffer but update the SAVE_MODIFF in order to simulate that no buffer
change occurred:

                  if (MODIFF - 1 == SAVE_MODIFF)
                    SAVE_MODIFF++;

I think that's innocuous but, if someone wanted to increment SAVE_MODIFF
in order to "ignore" a _text-property_ change only, the invariant above
could get violated.  Is anyone aware of whether such a hack exists or is
planned somewhere?


3. `first-change-hook' currently runs whenever a text-property is
assigned (by font-lock, for example).  I believe this should change with
the new function too?