From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.devel Subject: RE: On obsoleting defcustoms Date: Thu, 12 Nov 2020 19:07:44 -0500 Message-ID: References: > <83lfh743j8.fsf@gnu.org>> <53945b2b-cb3f-4823-85e1-ff8676f10161@default> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14758"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Drew Adams , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 13 01:08:42 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kdMdu-0003ld-Rm for ged-emacs-devel@m.gmane-mx.org; Fri, 13 Nov 2020 01:08:42 +0100 Original-Received: from localhost ([::1]:55094 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kdMdt-0004VJ-Ub for ged-emacs-devel@m.gmane-mx.org; Thu, 12 Nov 2020 19:08:41 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34030) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kdMd2-0003rk-Rv for emacs-devel@gnu.org; Thu, 12 Nov 2020 19:07:48 -0500 Original-Received: from mail-ej1-f41.google.com ([209.85.218.41]:35951) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kdMd1-0003uj-3C; Thu, 12 Nov 2020 19:07:48 -0500 Original-Received: by mail-ej1-f41.google.com with SMTP id o21so10724244ejb.3; Thu, 12 Nov 2020 16:07:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=t34pgo71+cY93hF9BLuktipIZiH021kCjGdZ/wV7Yk0=; b=NHBjjSlk6eRrEmYMxpykoyfvWV/vvRu/DU1jw44cOFJ7NvTPnzmTlXWiIv2XEZZJGD Tjqdy0+sDtJv4f4wRnVauRlnGDM8VudQyxBCVZ0vD97DNJBpgJNIOJh81KHPCuEFP8ql atW7igNwgTiAEqBwbvK0SXTOHari4ywivHlDjckBEg25vssicONfMjuwTxQRvBYZv/eI UHWdapxzJkPqC2TsMMrlpro68M0mMjtP/wOr7pqUV/ssBzl7ZJ25FAC8DHT+U8FCq5ED V3lXwaG40i9R8Ka2YdYek0OFheyK0tXm7o4n+kNyvpFE5WRg35W0qUtuRWQQ0KfxNOZj cVyA== X-Gm-Message-State: AOAM531AlN/CwKKbX6N3nP7ACt/DAGsyFSDWvqhSFnyliULXG/q3ODol d91fePeEjxe9B/7fyEwGdbE/OyCFPjGAMPPYcVI= X-Google-Smtp-Source: ABdhPJzJN81ou4icAc+Fba4QV4eLg2CwqaKJdr6HKh5ZIz3oxo1iN2LdrNNo3lj0DED8hgKFniGqaMKu2PTozlFeobk= X-Received: by 2002:a17:906:7797:: with SMTP id s23mr1811010ejm.312.1605226065132; Thu, 12 Nov 2020 16:07:45 -0800 (PST) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Thu, 12 Nov 2020 19:07:44 -0500 In-Reply-To: Received-SPF: pass client-ip=209.85.218.41; envelope-from=stefankangas@gmail.com; helo=mail-ej1-f41.google.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/12 19:07:45 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:259110 Archived-At: Drew Adams 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.