all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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.





  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

* 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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.