emacs-devel
[Top][All Lists]
Advanced

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

Re: emacs rendering comparisson between emacs23 and emacs26.3


From: Eli Zaretskii
Subject: Re: emacs rendering comparisson between emacs23 and emacs26.3
Date: Wed, 08 Apr 2020 10:40:19 +0300

> Date: Wed, 08 Apr 2020 10:10:07 +0300
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden, address@hidden,
>  address@hidden
> 
> > It's context fontification.  I'm quite sure of that, now.  To restart
> > jit-lock with a new j-l-context-time involves explicitly getting rid of
> > a timer and allowing it to restart.
> 
> Then perhaps the solution is to reduce the default value of
> jit-lock-context-time?

Btw, I cannot wrap my head around this "deferred context
fontification" stuff; never could.

The doc string of jit-lock-contextually says:

  If t, means fontification occurs on those lines modified and all
  subsequent lines.  This means those subsequent lines are refontified to 
reflect
  their new syntactic context, after `jit-lock-context-time' seconds.
  If any other value, e.g., `syntax-driven', means syntactically true
  fontification occurs only if syntactic fontification is performed using the
  buffer mode's syntax table, i.e., only if `font-lock-keywords-only' is nil.

I understand what t means and does, but what does non-nil, non-t value
do, and how is it different from t? in particular, does it also wait for
jit-lock-context-time of idleness?

The doc string of jit-lock-mode also seems to document only the t
value:

  - Deferred context fontification if `jit-lock-contextually' is
    non-nil.  This means fontification updates the buffer corresponding to
    true syntactic context, after `jit-lock-context-time' seconds of Emacs
    idle time, while Emacs remains idle.  Otherwise, fontification occurs
    on modified lines only, and subsequent lines can remain fontified
    corresponding to previous syntactic contexts.  This is useful where
    strings or comments span lines.

The code doesn't seem to start the jit-lock-context-timer if the value
is non-t, or am I missing something?  Since the default value is
'syntax-driven', where does that 0.5-second delay we all see come
from?  I guess you (Alan) have this figured out, so please share what
you've learned, and let's update the documentation to benefit from
that.

Thanks.



reply via email to

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