unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Kangas <stefan@marxist.se>
Cc: 44598@debbugs.gnu.org
Subject: bug#44598: [PATCH] Do not show obsolete options in customize
Date: Fri, 13 Nov 2020 09:40:52 +0200	[thread overview]
Message-ID: <83mtzlya9n.fsf@gnu.org> (raw)
In-Reply-To: <CADwFkmm4FUU8RRArBi2u_WOgM=PoYgtiuC-bgETe7X2jOiCWvQ@mail.gmail.com> (message from Stefan Kangas on Thu, 12 Nov 2020 15:56:24 -0500)

> Cc: eliz@gnu.org
> From: Stefan Kangas <stefan@marxist.se>
> Date: Thu, 12 Nov 2020 15:56:24 -0500
> 
> In a recent discussion on emacs-devel,[1]

You mean this one:

  https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg01617.html

> > IMO, we shouldn't show obsolete options at all in a Custom buffer, for
> > the same reason why we remove them from the manuals.
> 
> How about the attached patch?

Thanks, some comments:

> +** Customize
> +
> +*** Customize will no longer show obsolete user options.

This is too general, it sounds like those options will not be shown
even if the user types "M-x customize-variable" to explicitly
customize an obsolete option.  That's not what the patch does, does
it?

> -(defface custom-variable-obsolete
> -  '((((class color) (background dark))
> -     :foreground "light blue")
> -    (((min-colors 88) (class color) (background light))
> -     :foreground "blue1")
> -    (((class color) (background light))
> -     :foreground "blue")
> -    (t :slant italic))
> -  "Face used for obsolete variables."
> -  :version "27.1"
> -  :group 'custom-faces)

You are removing the face, but then how will we display obsolete
options when the user actually asks to customize them by name?

> +(defun custom--filter-obsolete-variables (items)
> +  "Filter obsolete variables from ITEMS."

This doesn't say what kind of object is ITEMS expected to be.

> +  (seq-filter (lambda (item)
> +                (not (and (eq (nth 1 item) 'custom-variable)
> +                          (get (nth 0 item) 'byte-obsolete-variable))))
> +              items))

Do we really need the power of seq.el here? wouldn't mapcar do the job
nicely, since we have a simple list here?  OTOH, if you do use seq.el,
why seq-filter and not seq-remove?

> +(ert-deftest cus-edit-tests-customize-group/no-obsolete ()
> +  "Check that obsolete variables do not show up."
> +  (save-window-excursion
> +    (unwind-protect
> +        (progn
> +          (customize-group 'cus-edit-tests)
> +          (should-not (search-forward "Cus Edit Testvar Obsolete" nil t)))
> +      (when-let ((buf (get-buffer "*Customize Group: Cus Edit Tests*")))
> +        (kill-buffer buf)))))

This test will fail when we remove the obsolete option, right?  How
can we come up with a test that doesn't suffer from such maintenance
problems?





  parent reply	other threads:[~2020-11-13  7:40 UTC|newest]

Thread overview: 14+ 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 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 [this message]
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

  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=83mtzlya9n.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=44598@debbugs.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).