From: Ihor Radchenko <yantar92@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 56637@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>
Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
Date: Wed, 20 Jul 2022 12:13:14 +0800 [thread overview]
Message-ID: <874jzc4e1x.fsf@localhost> (raw)
In-Reply-To: <837d49ntwg.fsf@gnu.org>
Eli Zaretskii <eliz@gnu.org> writes:
>> It would be nice if we could somehow enable font-lock inside " *hidden*"
>> buffers. Would it be possible?
>
> Depends on the "somehow" part. I generally prefer that obscure corner
> cases be solved in the software which creates those obscure cases. In
> this case, it seems like web-mode is that place? I'm not sure why
> you say Org should solve this, but perhaps I didn't understand the
> description well enough. But if this indeed needs to be solved in
> Org, how about not using buffers whose names begin with a space?
While this particular case might be solved on web-mode side (I guess
that directly setting 'font-lock-face property is not recommended?), I
am more concerned about similar issues that might popup in future.
Is it always guaranteed by Emacs that font-lock-fontify-buffer correctly
fontifies that buffer even when font-lock-mode is disabled? If not, Org
has to make sure that font-lock-mode can be enabled when we need to
compute fontification programmatically.
The need to compute fontification is not limited to the described Reddit
report. Org also needs fontification for export purposes - we copy the
Emacs code colours into exported documents. With current behaviour of
font-lock-mode, programmatic fontification may be problematic not only
when we use "hidden" buffers starting with space, but also in
non-interactive mode as in recent related bug report
https://orgmode.org/list/wxaUFiqi8BmIPv8pcYRVHAFa0hTzM35roQxpVVRkgddjRkesPGX1kVBL3G0fr42FonlRq5FNjapV8RiovXV-RGEDehXn-cmIebf4HWBhzIQ=@protonmail.com
As for not using buffers with names starting with a space, we do need
such buffers as means to fontify foreign major mode blocks inside Org.
How else do you suggest computing fontification of an arbitrary text in
arbitrary major-mode (not org-mode) without polluting the buffer list?
Best,
Ihor
next prev parent reply other threads:[~2022-07-20 4:13 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-19 4:15 bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers Ihor Radchenko
2022-07-19 12:55 ` Eli Zaretskii
2022-07-20 4:13 ` Ihor Radchenko [this message]
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=874jzc4e1x.fsf@localhost \
--to=yantar92@gmail.com \
--cc=56637@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=monnier@iro.umontreal.ca \
/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).