[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: jit lock sit-for provokes redisplay provokes imenu
From: |
martin rudalics |
Subject: |
Re: jit lock sit-for provokes redisplay provokes imenu |
Date: |
Fri, 21 Jul 2006 11:13:07 +0200 |
User-agent: |
Mozilla Thunderbird 1.0 (Windows/20041206) |
> 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?
Re: jit lock sit-for provokes redisplay provokes imenu, martin rudalics, 2006/07/21