all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: yantar92@posteo.net, 58888@debbugs.gnu.org
Subject: bug#58888: 28.1.90; font-lock-defaults not respected when hack-local-variables unsafe variable dialogue is displayed before setting the defaults
Date: Thu, 11 Apr 2024 09:27:44 -0400	[thread overview]
Message-ID: <jwvttk83w2m.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <868r1kv2ry.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 11 Apr 2024 09:20:33 +0300")

> Any idea how many major modes out there don't use run-mode-hooks?

Hard to tell.  I did a quick

    grep '^[^;]*kill-all-local-variables' $(grep -L run-mode-hooks **/*.el)

in our own code, and it shows a fairly large number of occurrences, but
once you look at them it's not clear what to make of them.  Many of them
don't bother to define an actual mode for the buffer, they just call
`kill-all-local-variables` then fill the buffer somehow, occasionally do
some major-mode-like setup such as `use-local-map`, and finally display
the result to the user.

> We are basically breaking those with this change, right?

Yes.  More specifically the minor modes defined with
`define-globalized-minor-mode` will stay inactive in them.

> Please don't quote `like this`.  (I think you should by now have a
> commit hook in your init files that replaces the quoting with our
> style, because this seems to be ubiquitous in all your writings.)

I do my best to follow the ugly `...' convention in ELisp file and the
'...' convention in our other files, but not for anything else.
I strongly prefer the Markdown convention over '...' because it's
a convention enshrined in many tools.  I could live with the Org
convention if you prefer, but I strongly feel that we should
use notational conventions that tools are able to use.

> IMO, this NEWS entry is not detailed enough.  First, it should mention
> that run-mode-hooks is the modern way of running the mode's hook, a
> replacement for run-hooks.  And second, it should at least hint on
> what will happen with modes which don't use run-mode-hooks, so that
> affected users could identify the problem when they see its signs.
>
> Also, I think we should tell in the ELisp manual that run-mode-hooks
> is now a must, not just a preference, and we should mention in the
> Minor Modes chapter that the globalized minor modes will work
> correctly only if the major mode uses run-mode-hooks to run its hooks.

I'll get back to this once we decide we do want the change.


        Stefan






  reply	other threads:[~2024-04-11 13:27 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-30  6:58 bug#58888: 28.1.90; font-lock-defaults not respected when hack-local-variables unsafe variable dialogue is displayed before setting the defaults Ihor Radchenko
2022-10-31  2:15 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-31  7:11   ` Ihor Radchenko
2024-04-08 12:48     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-08 13:15       ` Eli Zaretskii
2024-04-08 13:42         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-08 19:25       ` Ihor Radchenko
2024-04-10 20:34         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-11  6:20           ` Eli Zaretskii
2024-04-11 13:27             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2024-04-11 14:12               ` Eli Zaretskii
2024-04-13 14:32                 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-11 13:53         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-11 14:13           ` 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=jwvttk83w2m.fsf-monnier+emacs@gnu.org \
    --to=bug-gnu-emacs@gnu.org \
    --cc=58888@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=yantar92@posteo.net \
    /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.