unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Ihor Radchenko <yantar92@gmail.com>
Cc: 57447@debbugs.gnu.org
Subject: bug#57447: 28.1.90; Can font-lock stop requesting fontification of invisible text?
Date: Sat, 27 Aug 2022 10:02:39 +0300	[thread overview]
Message-ID: <837d2u184w.fsf@gnu.org> (raw)
In-Reply-To: <87fshi6ygu.fsf@localhost> (message from Ihor Radchenko on Sat, 27 Aug 2022 13:34:57 +0800)

> From: Ihor Radchenko <yantar92@gmail.com>
> Date: Sat, 27 Aug 2022 13:34:57 +0800
> 
> Org mode tends to hide large chunks of text under folded headlines.
> I expect this hidden text to be ignored by the font-lock engine.
> 
> However, in reality, there appear to be some scenarios when hidden text
> is, in fact, being requested for fontification.
> 
> I have an Org file with a number of folded headlines. 32 of them can fit
> into one screen of text on my system, when folded. The total character
> count contained within the folded headlines (both visible and inside the
> 32 hidden text chunks) is 12742. However, most of this text is folded, and only 2446 characters are visible in the buffer.
> 
> I expect font-lock to fontify around 2446 characters (32 lines), but
> Emacs instead requests fontification of 9374 characters (315 lines; 10
> screens of text) at once; ~1.5k chars for each folded text region.
> 
> Fontification of 10 screens of text is obviously 10x slower and can
> create noticeable feedback slowdowns.
> 
> Can anything be done to make Emacs fontify less (or none) of the hidden
> text?

I explained that recently, in a discussion in which you participated:
the display engine skips invisible text, but that cannot completely
avoid fontifications of some of the invisible text.

The technical reason for that is that the display engine considers the
'fontified' property before it considers the 'invisible' property (and
any other properties).  Since fontification-functions put text
properties on buffer text, the 'fontified' property _must_ be examined
first, and the fontification-functions _must_ be invoked _before_ the
properties are examined; otherwise we'd risk behaving incorrectly due
to outdated or not-yet-existing properties.

One way this could be improved is by making jit-lock-chunk-size
smaller.  This will make the probability of such "over-fontification"
lower.

If a mode _knows_ that no fontifications could ever produce invisible
properties or overlays, then its fontification-functions could stop
whenever they encounter invisible text.

> The fontification log is:
> 
> org-font-lock: About to fontify 13481..15094
> org-font-lock: Fontified drawer(13372..13487) completely.

Thanks, but this log is insufficient to analyze whether the code
functions correctly.  To do such an analysis one must know which text
parts (in therms of buffer positions) were invisible and which
weren't.  Also, you haven't shown the code which produces the log, so
the exact meanings of "about to fontify", "fontfied drawer", and the
rest of the log messages, as well as the numerical notations like
"13487:+235", are unclear.





  reply	other threads:[~2022-08-27  7:02 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-27  5:34 bug#57447: 28.1.90; Can font-lock stop requesting fontification of invisible text? Ihor Radchenko
2022-08-27  7:02 ` Eli Zaretskii [this message]
2022-08-27  7:45   ` Ihor Radchenko
2022-08-27  9:18     ` Eli Zaretskii
2022-08-27 10:37       ` Ihor Radchenko
2022-08-27 11:05         ` Eli Zaretskii
2022-08-27 11:11           ` Ihor Radchenko
2022-08-27 11:17             ` Eli Zaretskii
2022-08-27 11:24               ` Ihor Radchenko
2022-08-27 15:21           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-27 15:25             ` Eli Zaretskii
2022-08-28  1:23             ` Ihor Radchenko
     [not found]               ` <jwvtu5wsa21.fsf-monnier+emacs@gnu.org>
     [not found]                 ` <87r10xp07l.fsf@localhost>
     [not found]                   ` <jwvy1v4giz3.fsf-monnier+emacs@gnu.org>
     [not found]                     ` <875yi7o8x3.fsf@localhost>
     [not found]                       ` <jwvmtbjgmrs.fsf-monnier+emacs@gnu.org>
     [not found]                         ` <jwvo7vsb3fz.fsf-monnier+emacs@gnu.org>
     [not found]                           ` <8735d2pghv.fsf@localhost>
2022-09-09 14:52                             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=837d2u184w.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=57447@debbugs.gnu.org \
    --cc=yantar92@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).