From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 56637@debbugs.gnu.org, yantar92@gmail.com
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 14:12:29 +0300 [thread overview]
Message-ID: <83a694m40y.fsf@gnu.org> (raw)
In-Reply-To: <jwv4jzcbz6x.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Tue, 19 Jul 2022 17:12:44 -0400)
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: yantar92@gmail.com, 56637@debbugs.gnu.org
> Date: Tue, 19 Jul 2022 17:12:44 -0400
>
> Of course, people can use hacks like
>
> (defun really-turn-on-font-lock ()
> (unwind-protect
> (let ((noninteractive nil))
> (rename-buffer (concat "\0" (buffer-name)))
> (font-lock-mode 1))
> (when (eq ?\0 (aref (buffer-name) 0))
> (rename-buffer (substring (buffer-name) 1)))))
>
> But I can't see why we shouldn't accommodate those needs more directly.
I can: we don't need, and really shouldn't, attempt to cater to each
corner use case in core. Doing that (and we've been doing that for
quite some time) makes Emacs a larger and less maintainable monster
than it needs to be or already is. The gain for everyone is minimal,
the gain for those who must for some reason cope with such situations
is small (compared with the above alternative or something like it),
while the damage in terms of being able to know what Emacs does
without stepping through the code with a debugger -- that damage is
quite significant. You already have one symptom of the monster's
size: I already cannot tell which hooks are and aren't running in
temporary buffers without consulting the sources. Way to go, Emacs!
> It's not like there a deep technical reason why font-lock should not be
> enabled under any circumstance in those cases.
There are practical reasons why it shouldn't in the vast majority of
cases. The few rare cases which do have easy workarounds, and I see
absolutely no reason why they couldn't take one of them.
> >> If you don't like `font-lock-allow-in-temporary-buffer`, we could have
> >> a new function `font-lock-enable-unconditionally` which does the same as
> >> `font-lock-mode` but skips the (or noninteractive (eq (aref
> >> (buffer-name) 0) ?\s)) test.
> >
> > Ouch!
>
> I don't understand this reaction.
See above.
next prev parent reply other threads:[~2022-07-20 11:12 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
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 [this message]
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=83a694m40y.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=56637@debbugs.gnu.org \
--cc=monnier@iro.umontreal.ca \
--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).