all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Kangas <stefan@marxist.se>
To: Drew Adams <drew.adams@oracle.com>, Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: RE: On obsoleting defcustoms
Date: Thu, 12 Nov 2020 19:07:44 -0500	[thread overview]
Message-ID: <CADwFkmmX8gAvQyD-8-NRv32GRRK_Z6784WXTMJ_B9L7PCHpwVA@mail.gmail.com> (raw)
In-Reply-To: <df843827-6a6c-4628-9016-fa708f935217@default>

Drew Adams <drew.adams@oracle.com> writes:

>> 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.

We have the face `custom-variable-obsolete', but indeed the warning is
unfortunately only made explicit on the help screen.

>> in Emacs 27 for a bad case of what that might look like.
>
> What's bad about it?

There are more obsolete options than relevant ones.  (Including, e.g.,
the options for the now wildly irrelevant Mosaic browser.)

> 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.

The problem is that, AFAICT, it is not really feasible to have a
one-size-fits-all for how we go about deprecating options.  In some
cases it makes sense for them to continue to have effect during the
obsoletion period, but in other cases it does not.

I for one was bitten by this trying to customize an option that turned
out to simply no longer have any effect.  Should it have just been
removed in this case?  Well, it would of course have helped me.  But
third-party code that tried to use it would get the signal "Symbol's
value as variable is void" at run-time, instead of the much gentler
byte-compiler warning that it is obsolete.

Not showing it in `M-x customize-group' seems like a good compromise.

> 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).

The current proposal as discussed in the bug will keep both
`customize-option' and `customize-saved'.  So you can still customize
them using customize.



  reply	other threads:[~2020-11-13  0:07 UTC|newest]

Thread overview: 26+ 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
2020-11-13  0:07         ` Stefan Kangas [this message]
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
2020-11-12 20:56   ` bug#44598: [PATCH] Do not show obsolete options in customize Stefan Kangas
2020-11-12 21:11     ` Basil L. Contovounesios
2020-11-12 21:39       ` Stefan Kangas
2020-11-12 22:18         ` Basil L. Contovounesios
2020-11-13  7:43       ` Eli Zaretskii
2020-11-12 21:40     ` Drew Adams
2020-11-12 21:44     ` Mauro Aranda
2020-11-12 22:08       ` Stefan Kangas
2020-11-12 22:41         ` Mauro Aranda
2020-11-13  7:48       ` Eli Zaretskii
2020-11-13  7:40     ` Eli Zaretskii
2020-11-13 17:10       ` Stefan Kangas
2020-11-14 14:22         ` Eli Zaretskii
2020-11-20 13:37           ` 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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CADwFkmmX8gAvQyD-8-NRv32GRRK_Z6784WXTMJ_B9L7PCHpwVA@mail.gmail.com \
    --to=stefan@marxist.se \
    --cc=drew.adams@oracle.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@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.