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?
next prev 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).