Re: What's the best (i.e. least bad) way to re-redisplay?

[Alan Mackenzie]

Hello, Eli.

On Mon, Aug 23, 2021 at 22:35:22 +0300, Eli Zaretskii wrote:
> > Date: Mon, 23 Aug 2021 18:41:59 +0000
> > From: Alan Mackenzie <acm@muc.de>

> > I envisage a situation where an identifier is identified as a type during
> > jit-lock fontification, and thus font-lock-type-face needs to be applied
> > to all occurrences of this identifier.

> > The problem is, there will be occurences in the foreground window before
> > the one which triggered the fontification.  Redisplay will already have
> > passed this earlier buffer position.  So I need to trigger another
> > redisplay immediately after the current one.

> > What is the least bad way of doing this?

> You mean, the same identifier is somewhere in the same window-ful, but
> before the position where you suddenly decided your previous
> fontification was incorrect?  (Why is this a reasonable scenario,
> btw?)

For example, in a C file we have a function prototype without parameter
names:

     fooMain (foo);

, and later on this gets fleshed out:

     fooMain (foo bar)
     {
     ....
     }

The first occurrence will get fontified as a function call, I think.
Only when we pass the second occurrence do we see foo must be a type.

> > Currently, I'm thinking of something like the CC Mode fontification
> > functions setting a flag, and a repeating timer function testing this
> > flag every 0.025s, say, and triggering a redisplay if it's set.

> Why not simply call a one-time timer function that runs
> jit-lock-force-redisplay, when you decide that you need to refontify?
> jit-lock.el already does that in some cases.  I see no reason to have
> a periodic timer and a flag, because the same code that sets the flag
> could instead arm a one-time timer.

Thanks, that's exactly the answer I was asking for.  :-)  I didn't know
about jit-lock-force-display.

> > One problem is knowing whether or not redisplay is currently active.  Is
> > there a simple way to do this in Lisp?  (I know there is in C.)

> I don't understand your problem here.  Timers cannot run while
> redisplay works, because timers are only run by the main loop.  So
> when a timer runs, redisplay by definition isn't.

That was going off on a bit of a tangent.  If the above situation occurs
when we know we're not already in redisplay, we could simply call
redisplay without using a timer.  I suppose it's not really that important.

-- 
Alan Mackenzie (Nuremberg, Germany).