From: Ihor Radchenko <yantar92@gmail.com>
To: 56637@debbugs.gnu.org
Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
Date: Tue, 19 Jul 2022 12:15:33 +0800 [thread overview]
Message-ID: <874jzdhh5m.fsf@localhost> (raw)
Hi,
font-lock-mode contains the follow clause:
;; Don't turn on Font Lock mode if we don't have a display (we're running a
;; batch job) or if the buffer is invisible (the name starts with a space).
(when (or noninteractive (eq (aref (buffer-name) 0) ?\s))
(setq font-lock-mode nil))
which interferes with Org mode's fontification code in some edge cases.
Org mode fontifies code blocks using "hidden" temporary buffers with
their name starting from " ": " *org-src-fontification:major-mode*".
The buffers are kept around to avoid extra major-mode loading overheads
and the fontification is not using (font-lock-ensure).
(font-lock-ensure) usually fontifies the buffer correctly even though
font-lock-mode is disabled. However, not always.
We just got some edge case
https://teddit.net/r/orgmode/comments/w2b0tw/syntax_highlighting_in_orgsource_blocks/igqdx18/
with web-mode, which directly sets 'font-lock-face text properties.
Without font-lock-mode being enabled, 'font-lock-face is not
automatically remapped to 'face text property and hence some part of the
fontification may not be reflected by simply looking into 'face
property.
While Org can work around this particular case by looking into
'font-lock-face, I am not sure if disabled font-lock may not trigger
similar issues in other cases.
It would be nice if we could somehow enable font-lock inside " *hidden*"
buffers. Would it be possible?
Best,
Ihor
next reply other threads:[~2022-07-19 4:15 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-19 4:15 Ihor Radchenko [this message]
2022-07-19 12:55 ` bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers Eli Zaretskii
2022-07-20 4:13 ` Ihor Radchenko
2022-07-20 11:32 ` Eli Zaretskii
2022-07-21 12:09 ` Ihor Radchenko
2022-07-21 12:26 ` Eli Zaretskii
2022-07-21 12:44 ` Ihor Radchenko
2022-07-21 12:49 ` Eli Zaretskii
2022-07-21 13:18 ` Ihor Radchenko
2022-07-21 15:13 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-24 6:40 ` Ihor Radchenko
2022-07-19 16:13 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-19 16:36 ` Eli Zaretskii
2022-07-19 17:01 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-19 18:05 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-19 19:02 ` Eli Zaretskii
2022-07-19 19:21 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-19 19:32 ` Eli Zaretskii
2022-07-19 21:12 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-20 11:12 ` Eli Zaretskii
2022-07-20 15:15 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-20 16:09 ` Eli Zaretskii
2022-07-20 19:15 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-20 4:15 ` Ihor Radchenko
2022-07-20 14:58 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-21 12:11 ` Ihor Radchenko
2022-07-21 18:39 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-24 6:47 ` Ihor Radchenko
2022-07-24 14:25 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-25 9:23 ` Ihor Radchenko
2022-07-25 15:56 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-26 5:21 ` Ihor Radchenko
2022-07-23 7:53 ` Lars Ingebrigtsen
2022-07-23 8:55 ` Eli Zaretskii
2022-07-23 13:46 ` 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=874jzdhh5m.fsf@localhost \
--to=yantar92@gmail.com \
--cc=56637@debbugs.gnu.org \
/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).