From: Drew Adams <drew.adams@oracle.com>
To: Stefan Kangas <stefan@marxist.se>, Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: RE: On obsoleting defcustoms
Date: Thu, 12 Nov 2020 14:16:11 -0800 (PST) [thread overview]
Message-ID: <df843827-6a6c-4628-9016-fa708f935217@default> (raw)
In-Reply-To: <CADwFkmmdH9geMXj+u7Pgvo72JJ3_M5NZZjE3Qvfm=tuvdKJAgw@mail.gmail.com>
> > If people are concerned about someone continuing to use
> > something that's obsolete, why not just have Customize give
> > a warning/message saying that the option is obsolete
>
> That's what we do now. See `M-x customize-group RET browse-url RET'
I don't see any such warnings/messages there, until you
open the full doc string of an option. If every option
in the group is obsolete, and so is the group itself
(which should presumably follow), then one might expect
a notification at the top (i.e. customize-group) level.
> in Emacs 27 for a bad case of what that might look like.
What's bad about it?
If all of those options still "work", a user should be
able to make use of Customize to change their values.
And if they don't work then there should be no supporting
code, and they'd be unrecognized - raise an error if
referenced in any way. Typically, deprecated/obsolete !=
unsupported. Does Emacs take the point of view that all
of this is unsupported? If so, remove its code, so using
raises an error.
> > That's assuming that Emacs takes the (unusual, IME) point of
> > view that, once declared obsolete, something should no longer
> > be usable.
>
> It's still usable with the patch, just not advertised.
Not advertising is fine. Telling users, including in the
Customize UI, that something is obsolete is also fine.
What's not fine, IMO, is to remove it from Customize. If
something is removed from Customize then it's not the case
that it's still usable with Customize (or Customize is
still usable for it).
next prev parent reply other threads:[~2020-11-12 22:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <<CADwFkmm2G=OPOdgadhDk+1uCbHzuqpqaYDs1KgdDes7gXLYgxg@mail.gmail.com>
[not found] ` <<83lfh743j8.fsf@gnu.org>
2020-11-12 21:37 ` On obsoleting defcustoms Drew Adams
2020-11-12 21:54 ` Stefan Kangas
2020-11-12 22:16 ` Drew Adams [this message]
2020-11-13 0:07 ` Stefan Kangas
2020-11-13 1:59 ` Drew Adams
2020-11-13 3:10 ` Stefan Kangas
2020-11-13 5:18 ` Drew Adams
2020-11-13 8:16 ` Eli Zaretskii
2020-11-13 7:46 ` Eli Zaretskii
2020-09-18 13:01 Stefan Kangas
2020-09-18 13:28 ` Eli Zaretskii
2020-09-18 13:40 ` Stefan Kangas
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=df843827-6a6c-4628-9016-fa708f935217@default \
--to=drew.adams@oracle.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=stefan@marxist.se \
/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).