From: Drew Adams <drew.adams@oracle.com>
To: Stefan Kangas <stefan@marxist.se>
Cc: Roland Winkler <winkler@gnu.org>, 21563@debbugs.gnu.org
Subject: bug#21563: 24.5; discourage load-hook variables
Date: Thu, 16 Jan 2020 13:08:56 -0800 (PST) [thread overview]
Message-ID: <c4ff880d-2180-405c-bdec-8d993a4fae53@default> (raw)
In-Reply-To: <877e1r400b.fsf@marxist.se>
> > Here's what I'd suggest, if you are bent on removing
> > all load hooks and deprecating them:
> >
> > 1. Try removing all of them from the vanilla
> > (distributed) Elisp code.
> >
> > 2. Run with that for a major release or two. If no
> > problems, then deprecate (declare obsolete).
>
> I'm not sure I understand the proposal. What is the "vanilla
> (distributed) Elisp code"?
The code that GNU Emacs distributes.
> What does "removing all of them" mean, and
> how is removing them more cautious than adding a deprecation warning
> to the variables?
It doesn't matter to me whether you remove all or only
some. I meant remove them - any or all. The more you
remove, the more sure you are that deprecation might
make sense. Don't deprecate (step 2) before removing
them all, though, to be sure your replacement handles
all of the existing GNU Emacs cases, at least.
> Third party packages are free to continue doing that. AFAICT, we have
> no way to stop them -- and I wouldn't advocate for that.
For step 1, I'm suggesting that you _not_ deprecate
(declare obsolete) or recommend against. Otherwise,
you are prescribing something for 3rd-party code.
And you're doing that before you've actually tried
it thoroughly for your own code.
> Am I missing something here?
>
> I'm not sure if this was clear, but the course of action suggested by
> Glenn was to add deprecation warnings to the load-hook variables in
> GNU Emacs. Please see the attached patches for an example.
And that is just what I'm suggesting not to do. First
remove them from wherever you want from the GNU Emacs
code. Then wait, and see how that goes. Then, after
a release or two, provide your deprecation warnings.
There's no hurry for this, AFAIK. And these things were
added on purpose - they didn't fall from the sky. Wait
and see how things go. That's my suggestion.
It makes little sense (to me) to deprecate something
before you've even tried doing without it for a while.
Go on the diet yourself (not you, personally!) before
you start telling everyone outside core Emacs to go
on it. That's all.
next prev parent reply other threads:[~2020-01-16 21:08 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-25 18:57 bug#21563: 24.5; discourage load-hook variables Roland Winkler
2020-01-15 19:32 ` Stefan Kangas
2020-01-15 20:21 ` Drew Adams
2020-01-15 20:42 ` Stefan Kangas
2020-01-16 0:27 ` Roland Winkler
2020-01-15 22:06 ` Glenn Morris
2020-01-16 0:03 ` Stefan Kangas
2020-01-16 0:24 ` Drew Adams
2020-01-16 0:54 ` Stefan Kangas
2020-01-16 3:56 ` Drew Adams
2020-01-16 13:33 ` Stefan Kangas
2020-01-16 16:15 ` Drew Adams
2020-01-16 20:30 ` Stefan Kangas
2020-01-16 21:08 ` Drew Adams [this message]
2020-01-16 0:31 ` Stefan Kangas
2020-04-16 4:14 ` Stefan Kangas
2020-04-16 9:07 ` Roland Winkler
2020-04-26 14:33 ` Stefan Kangas
2020-10-20 17:16 ` Stefan Kangas
2020-01-16 11:49 ` Mauro Aranda
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=c4ff880d-2180-405c-bdec-8d993a4fae53@default \
--to=drew.adams@oracle.com \
--cc=21563@debbugs.gnu.org \
--cc=stefan@marxist.se \
--cc=winkler@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 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.